Hacker News Reader

Comment by kazinator | Hacker News Reader

I'm not a fan of Unix man page section numbers in parentheses.

strlcpy is a stopgap, whack-a-mole solution for buffer overflows. It is rationalized by the reasoning that it does not make the program less wrong, while (probably) making it more secure.

When truncation matters and you have a fixed size buffer, that buffer should be large enough in order for it to be justifiable to say that someone is misusing the application. Perhaps a tester trying to break it.

Nobody’s surname needs 128+ bytes. No reasonable URL for a firmware update download needs 4096 bytes.

If truncation matters, no, it does not always make sense to accept a gig of data and be ready for more. You can impose a limit. A violation of the limit is an error, treated like a case of bad input.

View on HN

People have long surnames, especially if you take multi-byte characters into account. And someone with the same mindset as you is the reason why my profile picture in Google’s employee directory never did actually show up in Safari–one of the path components ended up being a couple thousand characters long (I wonder if it was literally a base64 encoding of the image itself?)

Out of curiosity, would you mind sharing some details about your surname?

E.g., its length in its native alphabet, or its length as a UTF-8 string?

  $ swift
  Welcome to Apple Swift version 6.0 (swiftlang-6.0.0.5.15 clang-1600.0.22.6).
  Type :help for assistance.
    1> "झा".count
  $R0: Int = 1
    2> "झा".utf8.count
  $R1: Int = 6

No, my reasoning does not say that a browser shouldn't handle a long URL (which is a substring of a page it has already accepted and rendered).

I fail to see the difference here?

> Nobody’s surname needs 128+ bytes.

https://en.wikipedia.org/wiki/Hubert_Blaine_Wolfeschlegelste.... would beg to differ.

I'm not sure his name is long enough for this to be an issue.

The URL uses a shortened version, his full name on the page is:

Adolph Blaine Charles David Earl Frederick Gerald Hubert Irvin John Kenneth Lloyd Martin Nero Oliver Paul Quincy Randolph Sherman Thomas Uncas Victor William Xerxes Yancy Zeus Wolfeschlegelsteinhausenbergerdorffwelchevoralternwarengewissenhaftschaferswessenschafewarenwohlgepflegeundsorgfaltigkeitbeschutzenvorangreifendurchihrraubgierigfeindewelchevoralternzwolfhunderttausendjahresvorandieerscheinenvonderersteerdemenschderraumschiffgenachtmittungsteinundsiebeniridiumelektrischmotorsgebrauchlichtalsseinursprungvonkraftgestartseinlangefahrthinzwischensternartigraumaufdersuchennachbarschaftdersternwelchegehabtbewohnbarplanetenkreisedrehensichundwohinderneuerassevonverstandigmenschlichkeitkonntefortpflanzenundsicherfreuenanlebenslanglichfreudeundruhemitnichteinfurchtvorangreifenvorandererintelligentgeschopfsvonhinzwischensternartigraum Sr.

Active Directory would cry.

He should have added a few numbers in there to really throw off some login systems.

And spaces.

I love that the guy's occupation was "typesetter".

That surname is like 22 bytes

That's the shortened version. The full version of the surname is 666 characters.

I apologize, I should've read more of the article. My bad

I guess it kind of goes to the poster's point, since Wikipedia articles truncate at 255 bytes (Since that was the max size of a VARCHAR in mysql 3)

A couple jobs ago, I worked on writing an API client for a CRM system that supported 2GB for most of the text fields (name, address line 1, job title, etc...). It also offered up 99 "custom field" text fields, also allowing up to 2GB each.

I'd considered base64-encoding my ripped DVD collection, and using them to store another backup copy for me.

The exception proves the rule. There is no way to read the description of the translation of the surname without coming to the conclusion that this was name was chosen for mischief, outside of the bounds of reasonable human societal expectations. Mischief is fine and all but there is no authentic "gotcha" compulsatory requirement for society to accomodate the chaos resulting from such a mischievous personal preference. (and I say this as someone who has legally changed his name twice)

tl;dr Make you bed; lie in it.

For conventions of the English language, this is an exception, but not in other languages. Arabic names have up to five components. A 128-byte limit leaves an average of 25 bytes for each component. Consider that Arabic script in UTF-8 consumes 2 bytes per glyph, and graphemes in Arabic are compositions of these glyphs.

For a more extreme example, consider conventions of Japanese. Middle names do not exist in Japanese. In fact, middle names are impossible to input into the 戸籍 (family registry). Forms in Japan are designed around the assumption that each person has exactly two names. Many Europeans would be unable to input their full name in such system. In this example, it'd be unreasonable to suggest most Europeans are acting "outside of the bounds of reasonable human societal expectations".

In general, the most effective solution I've seen for handling names is to have a single name field and treat it opaquely. If you need an inflection, ask for that separately.

> In general, the most effective solution I've seen for handling names is to have a single name field and treat it opaquely. If you need an inflection, ask for that separately.

Yes, in general. Though sometimes you need to know about specific parts of a name as interpreted in a specific cultural context.

Eg in Germany by law you need to register a family name when you get married, and your kids are going to have that family name, if you want it or not. (The parents don't necessarily have to have that name, eg the parents can opt for double-barrelled names or they can keep their old name. But the kids only get one family name and they all get the same name, and there are restrictions on which name you can pick.)

In contrast, here in Singapore they just give you a blank space in a form where you can put in your new baby's complete name as you please.

(OK, technically, you get multiple blank spaces, because you can eg give your kid a western name like Jay Random Smith and a Chinese name that is a completely separate name and doesn't need to have anything to do with the western name. I think you can also get eg a tamil name, if you want to etc.)

Compare Mr Karl-Theodor Maria Nikolaus Johann Jacob Philipp Franz Joseph Sylvester Buhl-Freiherr von und zu Guttenberg https://en.wikipedia.org/wiki/Karl-Theodor_zu_Guttenberg

And he's not even the guy with the longest name, and his parents did not make up his name to spite some length restrictions.

He would be too busy begging numerous agencies to handle his name to beg to differ with you.

Is there a picture of the ID page of that man's passport? Or of a driver's license or similar?

Whatever is on that is his actual name.

Surprised nobody has linked this yet:

https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

Also note that while the counter examples might sound extreme, in some languages each character might need 3 bytes in UTF-8, and 128/3 ~= 43 characters doesn't seem to be that outrageous.

> Nobody’s surname needs 128+ bytes

Oh we're doing that "false things that programmers believe about the world" again! Fun! Let's consider cultures where people can have more than one surname. Ever heard about Pablo Diego José Francisco de Paula Juan Nepomuceno María de los Remedios Cipriano de la Santísima Trinidad Ruiz y Picasso? Yes, that's his full name. Of course, he didn't frequently use it, but if you make a system dealing with people's names, you'd eventually end up having to support something like that.

In this case, his family names (Spanish people have two) were just "Ruiz y Picasso", the rest was is given name. So you can argue that his family name fits within 128 bytes.

But that brings us to the assumption that people have just one family name with is just one word, which is very much not the case in many cultures around the world.

A programmer who believes surnames are one word has not heard of John Von Neumann.

And then there's the assumption that you'd write it in that way, and in that order. There might be situations where you'd want to use the Hungarian and write "Neumann János" instead.

I.e. the assumption that the family names come last is not necessarily correct even in Europe. Let alone if one deals with the various Chinese languages, Japanese, or Korean. And probably others.

That is also true. I am currently working in an international project in Japan, so when designing our systems and databases I always insists on the terms "given" and "family" names instead of "first" and "last" names, to prevent confusions.

Same with the dates. I always ask my colleagues to please write the years in full, otherwise it can be very difficult to know if it is DMY or YMD (thankfully we don't have to deal with MDY).

> Nobody’s surname needs 128+ bytes.

According to Wikipedia some joker did have a 666-character surname, officially, in the USA. Perhaps the best thing to do would be to truncate the field at some reasonable limit to prevent people from crashing your system with ridiculous values but make sure your system works properly with the truncated names so, for example, it doesn't panic because the truncated name isn't equal to the original name.

With spaces, punctuation and diacritics, comparing even short names for equality is a bit dangerous and probably best avoided. If you expect two text fields to match and they don't, even after normalisation, you could consider flagging the case for human review later but continuing without an error for the time being.

If I'm understanding correctly what you mean by "joker", it sounds like the changed their name to be this long intentionally? That seems like the type of thing where most software probably can get away with just not supporting then; with the possible exception of mandatory government services or something, there's no reason software should need to account for people taking such extreme steps of their own volition.

Because programmers are too lazy to properly handle long names? That's a stretch for denying someone service and you know it.

Like, yes, nobody is forced to accept their name unless they're running a government service, but using it as an excuse is just that, an excuse.

To be clear, I'm not arguing for or against a specific value as the "maximum length" of a name. I'm drawing a distinction here in terms of a potential user's intentional choices and what that means for providing support.

> Because programmers are too lazy to properly handle long names? That's a stretch for denying someone service and you know it.

I don't think someone should be denied service if they happen to have a long name, but I genuinely don't think it's a stretch not to try to handle people going out of their way to subvert expected norms. In this case, the argument is more philosophical than technical because there isn't an obvious heuristic for determining whether a name is intentionally made long or not, but there are places where I do think it's worth it for programmers to consider.

As an aside, I'd argue there's more nuance than "properly handling long names" or "being lazy. There's already an inherent limit on how large a name can fit into memory, and that limit might even fluctuate depending on the number of users being processed in a server at a given time and how much memory a given server has. Is a 1 GB name too long to be worth handling, or is not handling it "laziness"? If you're arguing that any name that the government accepts should be accepted by any software, how do you know what the limit is that the government will accept? If you have international customers, is the limit larger? If there's no documented limit, do you just need to hope your software is at least as robust as the government's? My point isn't that these situations are equivalent to a name that's 666 characters long, but that arguing that not handling 666 characters is lazy already is a blend of implicit technical assumptions (servers have enough memory that handling names with 666 characters isn't an issue) and social assumptions (it's possible for someone to actually have a name that long), and I don't think that "pretend all names can fit into memory fine and just crash or time out or something if there are too many names that are too long according to the parameters of the runtime and the hardware" is the obvious best choice from a fairness perspective.

Any system will have some limit on the length of names - if nothing else, the budget for storage.

A non-lazy programmer will determine an appropriate limit, document it, continuously test that the entire system can handle that length correctly, and continuously test that helpful errors are returned when too-long names are input.

What if my legal name is 500 trillion characters long? Should every project design their storage system to accommodate this?

If you look at the 666-character name, it's no more or less ridiculous than 500 trillion characters.

Ask the government whether your legal name can be that long. They'll say no.

> nobody is forced to accept their name unless they're running a government service

I dunno, would you expect that the government should be allowed to dictate how long a person's name can officially be? If yes, then problem solved, nobody may have names longer than X, and all services will accept X. If no, then there has to be a practical limit on name sizes that government services can accept, and people will be unhappy because it doesn't accept their "official" name.

Alas, that only works if you are dealing only with people under the jurisdiction of the government in question.

There's always them pesky foreigners.

There's also the fact governments aren't static. The past, and future, are foreign countries.

Handling arbitrary length input without caring how that could be abused is also lazy.

If you're working in a stack that nicely handles arbitrary lengths, it takes extra consideration and effort to put in limits.

You can deal with jokers: https://find-and-update.company-information.service.gov.uk/c...

He allegedly told the utility company that he wouldn't pay his bill unless they spelled his name correctly, which caused them to print it on three lines. Maybe this guy is just a walking software test case?

The bill just needs the correct account number and address.

You don't get to just stipulate new conditions for paying your bill. If it's not in the service contract that your giant name has to be spelled completely on the bill for it to be payable, then that condition doesn't exist.

Are you a lawyer with expertise in Philadelphia commercial law of the 1950s? I'm sure not, so I wouldn't want to take that fight. It was apparently easier for the company to just write the guy's name correctly.

Or maybe Wikipedia is wrong, or the source was bad. You have to pay to read the 1955 article and I can't be bothered right now. Citation 16 below if you're interested.

https://en.wikipedia.org/wiki/Hubert_Blaine_Wolfeschlegelste...

That’s exactly what MICROS~1 did with the 8.3 file names on DOS. To add support for longer file names in systems that did not do so originally.

> Nobody’s surname needs 128+ bytes.

This attitude ensures that the US software industry will never conquer the world.

The US software industry has already conquered the world, and continues to do so. It doesn't mean that it'll always be this way, but if you wanted to associate software with a single country, then the US would be your answer.

Why does it need to conquer the world? I just want to deal with sane, performant software.

And people in other locales want to be able to use their own name without software mangling it.

At some point there is a physical limitation, there's no passport in the world that accepts a 666-character name.

The US only gives you 21 characters on the DS-11 for a surname.

You're assuming one character is stored as one byte, which is only the case for English.

That sounds like a them problem. ;D

I once heard that "decision" comes from a Latin root word meaning "to cut off (the other options; to pay opportunity cost)". I will decide to optimize for my use case.

I just want to deal with sane, performant people.

We'll just both need to learn to live with disappointment.

> nobody's surname needs 128 bytes

I believe that's #6 falsehoods programmers believe about names (with examples)

https://shinesolutions.com/2018/01/08/falsehoods-programmers...

Ingoring multi byte characters there are still plenty of long names https://www.ancestry.com/c/ancestry-blog/discovering-the-his...

If you're going to try for a "reasonable" max name length it would probably need to be at least 4kb.

Names are hard, don't force things into your assumptions.

If you must, record fields such as:

Full Legal Name - Freeform input no string input limitation. If you feel like this is an attack vector, send the data out for human review.

Full Mailing Address - Don't try to break this down, allow multi-line, free form input. This is something you might want to validate with your shipping carrier and/or a human.

A short 'nickname' used as such.

You always need size limitation. You really don't want to allow 10GB strings to be stored in the full name field.

Also, in almost any situation where you need a legal name, you actually want to follow a lot of rules. This idea that people's original names are somehow sacrosanct is a misunderstanding. If you're doing business in a European country for example, you have to write your name in Latin/Cyrillic letters, perhaps with a few symbols like ' or - allowed as well, and typically with a few accents/diacritics specific to each country. You certainly can't register as 田中 in any context that requires a legal name in France, you'd have to write that as Tanaka.

And this is natural because legal records are meant for authorities in some specific country to read, and compare with other legal docs - so they need to at least be readable to those authorities.

A 10GB string does sound pathologically large; however it's an argument about the absurd.

What size is for sure enough? Well I'm not so sure. What if someone has a lot of titles. What if society decides that someone's Legal Name requires a post quantum cryptography key that happens to be 20MB (binary) long?

Also, FYI, at least PostgreSQL doesn't give you a free lunch for any variable length string; length requirements are a column constraint that DEGRADES performance because it has to check.

An external name validator of some sort could check things. Commonly allowed cases could pass by computer check, while actual humans could review edge cases. Someone trying to abuse the name field like that probably needs human review elsewhere anyway.

I would bet you that Postgres insert and query performance is better overall if all names in your table are, say, up to 10KB long than if you have a bunch of bots inserting 20MB-long "names". And 10GB long strings are just not supported by Postgres, at least with default settings.

And the point of adding limitations on length is that you shouldn't even accept the HTTP request if it passes some size, as it will severely degrade performance if you allow someone to upload a 10GB string, even if you separate it into a human review area.

Finally, if the legal requirements change and legal names can legitimately contain cryptographic material, than your system has to change. There is no point in designing a system that tries to work for any possible use case.

Names aren't actually that hard. It's perfectly reasonable to assume that your system is going to be used in your country and culture, and handle the cases which are relevant for that. Edge cases within that context, and expanding to other cultural contexts, can be handled as they come up. But until then, YAGNI.

> Nobody’s surname needs 128+ bytes

128 bytes would only be 42 characters if each character uses 3 bytes, as would be the case in some languages. Which isn't an unreasonable length, especially if the name has a lot of combining characters.

Ok, let's make it 50 Unicode codepoints.

> Nobody’s surname needs 128+ bytes

That is only 32 astral characters... Seems kind of close for comfort. Not to mention combining characters

> I'm not a fan of Unix man page section numbers in parentheses.

Why not? Confusion if function call with section number as argument?

I once learned what they mean.

But I forgot and now do not.

They describe the section of the manual, where 1 = programs, 2 = syscalls, 3 = userspace functions, 4 = special files, 5 = file formats, 6 = games, 7 = misc/overviews.

So printf(1) is the man page for the /usr/bin/printf command, while printf(3) is the man page for the libc printf() function.

Alternatively, readdir(2) is the man page for the readdir syscall, while readdir(3) is the man page for the libc wrapper, which no longer actually calls readdir(2). See also syslog(2) and syslog(3).

Or, time(1) is the man page for /usr/bin/time to time how long commands take. time(2) is the syscall to return the number of seconds since the epoch. And time(7) gives you an overview of time and timers on the system.

I just discovered that typing man 'printf(1)' or man 'printf(3)' actually works (at least with the man command on Ubuntu, provided by the "man-db" package).

You have to quote or escape the parentheses because they're shell metacharacters, which IMHO makes that syntax more trouble than it's worth.

Other commands that work are "man 3 printf", "man -s 3 printf", and "man printf.3". I think "man 3 printf" is the oldest version.

At least one other version of the man command (NetBSD) doesn't accept "man printf.3" or "man 'printf(3)'".

Unless you're on a UNIX system the number isn't important. If you are on a UNIX system, then it's useful for telling the difference between commands (like write(1), hostname(1), or printf(1)), system calls (like write(2)), library functions (like printf(3)), or config files (like hostname(5)).

In an article about C programming, the context tells you that everything that is given in a typewriter font is a C identifier, unless noted otherwise.

It's visual clutter that only communicates

- I see the entire computing world with Unix blinders on my eyes.

- I can't imagine a strlcpy function being used on a system that isn't Unix and that doesn't have a man page for it in section 3.

- I don't care that C has been internationally standardized since 1989 with a printf(3) function; printf(3) it's just another Unix function in section 3 of my man pages.

- If I don't affix (2) or (3), how will people know I'm not talking about something other than a C library function? I don't understand this "context" stuff in writing and speaking.

> Nobody’s surname needs 128+ bytes. No reasonable URL for a firmware update download needs 4096 bytes.

...and surely the "seconds" field of a timestamp is always between 0 and 59 inclusive, addresses will include a state and a building number, phone numbers contain only digits and maybe a leading + sign, etc.

Wrong assumptions like this are one of the root causes of (in the best case) bad UI or (worst case) annyoing bugs.

128 bytes for a surname is only about 60 unicode characters, less if you include RTL markings and characters outside the BMP.

A URL can contain SHA hashes (think: reproducible builds) and can thus be very long (okay, 4k characters is pushing it quite a bit but I wouldn't rule it out like you did...)

> Wrong assumptions like this

Assumptions, or features? I'm all for inclusive behavior, however I'm also for well tailored solutions. Having support for 8k characters when you are going to usually use maybe 20 isn't smart or correct either. That's why we have utf-8, not utf-32, you can grow the bytes when you need to, but only then.

> A URL can contain SHA hashes

It can, or it can not - again, perhaps a feature, not a bug. The hash can also live in a file named by convention, and downloaded/checked separately. Maybe there are other scenarios where you might need a really long url, but domain + release path + name + major.minor.patch should get you 99% of the way.

What's "reasonable" is relative, always designing for the edge case is good in some cases, but its also OK (and perhaps better) to optimize on occasion.

There have to be limits somewhere. Memory and storage space is not infinite. On the other hand, "how many characters can someone have in their name" is infinite. That means that no matter what limit you choose, someone will eventually exceed that limit. And you have to have a limit.

This is not a matter of "wrong assumptions". At the end of the day, all you can do is set a limit such that you're comfortable with the risk that someone will be outside the limit you have set. And risk tolerance, as always, is a matter of opinion and not fact.

This is a poor argument.

Firstly, "how many characters can someone have in their legal name" is decidedly not infinite, because it has to be sufficiently short that some governmental entity was willing to record it.

Secondly, as a reply to a comment (quite reasonably) pointing out that 60 unicode characters may not be enough for a surprisingly large number of people, this makes even less sense. Memory and storage space are not infinite, but 128 bytes per name is still unreasonably low. One could buy a single 12TB hard drive and store the names of every single living human, allocating 1.5KB per person.

> it has to be sufficiently short that some governmental entity was willing to record it.

How short is that, exactly?

It's not hard to apply an upper bound here.

If you arrive at a government office when they open for the day, and try to spell out your name to the clerk, and are unable to finish before the office closes for the day, that name is too long.

Realistically they will probably tell you to leave well before that.

No one will have a legal name longer than the legal system will allow them to have.

The point is, you are always going to exclude some number of people's names when you set constraints. So you have to decide what is right for your use case, just like with any other engineering decision. There's no such thing as "right" or "wrong" here, simply what is best for the context. 128 bytes for a name is going to be unreasonably low in some contexts (e.g. for Arabic names), but not for others (e.g. for American names).

We live in a global society and there are plenty of Arab Americans so Arabic names are American names.

Upthread, I was the one who posited the 128 byte figure. It was for a surname, not full name.

I now posit 50 unicode codepoints for a surname.

Fit or fuck off.

When I was in college, the only number in my mailing address was the zip code.

THIS. Not for every use case, obviously. But for huge number of them. And the "FooBaz length 5307 bytes in check_input(), truncating to 4095 bytes..." errors (which are trivial to log, or ignore, as you wish) can reveal many interesting things.

128 bytes is only 4 32-bit characters. Now, I think 4-byte UTF-8 characters are pretty rare, but at least 3-byte ones are certainly common in names, even legal names.

If you allow users to type emojis in their name you will definitely run out as the color/gender selectors take up an additional code point.

You confused bits with bytes. 128 bytes can encode 32 4-byte long characters.

Reply on news.ycombinator.com