- Is this safe? - 11 Updates
- Found a use case for `const` by value return, a shared queue - 2 Updates
- Order of addresses of string-literals inside a translation unit - 3 Updates
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Feb 24 08:48AM -0800 > Well, now I have. > From the link: > #define EOF (-2) /**< End-of-file (usually from read) */ On implementations that have 8-bit chars, a reasonable choice for EOF is -SCHAR_MAX-2. |
| Muttley@dastardlyhq.com: Feb 24 05:05PM On Fri, 24 Feb 2023 18:20:30 +0200 >Eastern Arabic numerals, it would need to be able to recognize these >numbers. These numbers would be used in "mathematical operations by the >compiler" and would thus matter "from a programming POV". man isdigit: DESCRIPTION The isdigit() function tests for a decimal digit character. Regardless of locale, this includes the following characters only: ``0''``1''``2''``3''``4'' ``5''``6''``7''``8''``9'' The isnumber() function behaves similarly to isdigit(), but may recognize additional characters, depending on the current locale setting. |
| Muttley@dastardlyhq.com: Feb 24 05:09PM On Fri, 24 Feb 2023 17:20:32 +0100 >> We're not talking about the language, we're talking about API functions. >> the is*() functions unlike printf are not built in to the compiler. >I don't know what distinction you are trying to make, but I really think The distinction is that with built in functions the compiler can tell you if you're passing daft values. Eg: many compilers will warning you if you try to pass a non pointer to %s in printf which they couldn't do at compile time if printf was a normal library function. >> I'm aware how it does work. I'm also saying that crashing is a bug. >Yes - the bug is in the code that calls the function with invalid inputs. No - the bug is in the library function not bounds checking indexes into an array. Do you think not bounds checking a C array index is professional code? A simple yes/no will suffice. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Feb 24 12:16PM -0500 On 2/24/23 11:20, David Brown wrote: ... > the C standards, which do not distinguish between the "core language" > and the "standard library" - both aspects are part of the C programming > language. That's not quite the case. Section 6 is titled "Language", and section 7 is titled "Library", so it does distinguish them - but it provides specifications for both, and mandates that in a conforming implementation, they work together to meet the requirements imposed upon the implementation. Since we are discussing the C standard in comp.lang.c++ (without having veered off-topic - the C++ standard defines the behavior of the <ctype> functions only by cross-referencing the definitions of the <ctype.h> functions in the C standard), it should be noted that it isn't quite the same in the C++ standard. Sections 16-32 of the C++ standard each have a title referring to the C++ standard library, but sections 5-15, which describe the C++ language, don't say so in their titles. However, section 4.2p1-2 does explicitly describe this organizational structure |
| Paavo Helde <eesnimi@osa.pri.ee>: Feb 24 07:24PM +0200 > ``5''``6''``7''``8''``9'' > The isnumber() function behaves similarly to isdigit(), but may recognize > additional characters, depending on the current locale setting. Where did you see "isdigit" in my last response? If not, why bring it up again? Compilers written in other languages might even not have isdigit(), but would still need to parse numbers in whatever target language they are compiling. |
| scott@slp53.sl.home (Scott Lurndal): Feb 24 05:32PM >if you're passing daft values. Eg: many compilers will warning you if you >try to pass a non pointer to %s in printf which they couldn't do at compile >time if printf was a normal library function. Why do you think that? void log(const char *, ...) __attribute__((format(printf, 2, 3))); size_t trace(const char *, ...) __attribute__((format(printf, 2, 3))); |
| David Brown <david.brown@hesbynett.no>: Feb 24 06:39PM +0100 On 24/02/2023 18:16, James Kuyper wrote: > title referring to the C++ standard library, but sections 5-15, which > describe the C++ language, don't say so in their titles. However, > section 4.2p1-2 does explicitly describe this organizational structure While there are different sections of the standards that cover the library in detail, the standard libraries (in both C and C++) are intertwined with the "core language" to some extent. For example, the C "sizeof" operator returns a type that is declared in library headers, some uses of the C++ "new" operator require inclusion of a standard library header, and both languages have standard library functions that cannot be implemented purely in the language itself. Sometimes it is useful to distinguish a bit between "core language" features and "standard library" features, and sometimes compilers and standard libraries are implemented by separate groups. But they are still defined in the same standards documents, still part of an "implementation", and of very limited use if considered separately. |
| David Brown <david.brown@hesbynett.no>: Feb 24 06:42PM +0100 > if you're passing daft values. Eg: many compilers will warning you if you > try to pass a non pointer to %s in printf which they couldn't do at compile > time if printf was a normal library function. Did you not understand anything I wrote? Or are you just refusing to learn in the mistaken belief that learning makes you look bad? > an array. > Do you think not bounds checking a C array index is professional code? > A simple yes/no will suffice. Do you intend to stop asking stupid questions? A simple yes/no will suffice. Oh, wait, some questions don't make sense as they stand - and certainly don't make sense in the context of a yes/no answer. |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Feb 24 09:46AM -0800 On Friday, February 24, 2023 at 12:06:13 PM UTC-5, Mut...@dastardlyhq.com wrote: ... > of locale, this includes the following characters only: > ``0''``1''``2''``3''``4'' > ``5''``6''``7''``8''``9'' That is perfectly correct, but it less authoritative than the citations from the C standard which have already been posted to this thread, and say the same thing (though less directly). |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Feb 24 10:03AM -0800 David Brown <david.brown@hesbynett.no> writes: [...] > headers, some uses of the C++ "new" operator require inclusion of a > standard library header, and both languages have standard library > functions that cannot be implemented purely in the language itself. I mostly agree, but I don't think sizeof is a good example. The language-defined sizeof operator yields a result of an implementation-defined unsigned integer type. The library provides a name for that type, but a program can use sizeof without referring to that name. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */ |
| David Brown <david.brown@hesbynett.no>: Feb 24 07:59PM +0100 On 24/02/2023 19:03, Keith Thompson wrote: > implementation-defined unsigned integer type. The library provides a > name for that type, but a program can use sizeof without referring to > that name. Fair point. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Feb 24 08:34AM -0800 > char *dest_pointer = dest; > while (*source != '\0') *dest_pointer++ = *source_pointer++; > I would call that moving the data, not processing the data. I think it's fair to say that any effort that involves activity by the processor may be called processing. Furthermore your earlier message says "displays". The code shown doesn't do any displaying. |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Feb 24 06:48PM +0100 On 2023-02-24 4:51 PM, Tim Rentsch wrote: > facts, you would simply limit the line lengths of your postings > to 80 characters, as many coding standards and style guidelines > recommend. Even better, that you updated to more modern software. :-o - Alf |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Feb 24 08:55AM -0800 > occurrences of "Hello, world!" in a given program point at the same > location in memory, and to make "Hello, world!" + 7 == "world!". Both > optimizations have actually been implemented by many implementations. It's true that two or more string literals may have some bytes in common, but that's not because writing to a byte in a string literal has undefined behavior; it's because there is an explicit statement in the C++ standard (and also the C standard) that allows it. If anything the implication goes the other direction: because pre-standard C implementations stored multiple string literals in the same memory, when C was standardized it was pretty much a necessity that storing into the bytes of a string literal had to be undefined behavior. Nitpick: a string literal need not be a string (as the C standard points out, in a footnote IIRC). |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Feb 24 09:03AM -0800 Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: [string literals may overlap] > I hadn't realized until now that the standard allows two evaluations of > the same string literal to refer to distinct objects (and it's difficult > to imagine an implementation choice that would make them distinct). IIANM the statement about two evaluations is present in C++ but not in C. |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Feb 24 09:43AM -0800 On Friday, February 24, 2023 at 11:55:33 AM UTC-5, Tim Rentsch wrote: > the same memory, when C was standardized it was pretty much a > necessity that storing into the bytes of a string literal had to > be undefined behavior. True. But the fact that storing into the bytes of a string literal has undefined behavior is what makes storing multiple string literals in overlapping memory workable. We're really saying the same thing, from two different points of view. > Nitpick: a string literal need not be a string (as the C standard > points out, in a footnote IIRC). I agree, but not, I suspect, in the sense that you mean it. A string literal is a source-code feature. The corresponding string that I was referring to is created at run-time, so they can't be the same thing. That array is guaranteed to be null-terminated, and therefore always contains at least one string, which might be empty (as in ""). The value of a string literal not used to initialize an array is a pointer to the first element of that array, which is also necessarily the start of the first (and possibly only, possibly empty) string contained in that array. It is that string which I was referring to when I mentioned the "corresponding string". |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment