Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.lang.c Subject: Re: Comments on proposed C standard Message-ID: <6632@sun.uucp> Date: Thu, 28-Aug-86 05:43:33 EDT Article-I.D.: sun.6632 Posted: Thu Aug 28 05:43:33 1986 Date-Received: Thu, 28-Aug-86 23:41:35 EDT References: <2807@watmath.UUCP> Distribution: net Organization: Sun Microsystems, Inc. Lines: 151 > According to the standard, an operation like > > int i; > i /= 3.5; > > would be performed using floating point division. However, > the Berkeley C compiler uses integer division. For this > reason, this should be marked as a quite change. *Which* "Berkeley C compiler"? The 4.3BSD one performs this operation correctly; it uses floating-point division. The 4.2BSD compiler (and probably the System III compiler it was derived from) had a bug which made them do integer division in this case. As such, there is no need to make note of this, as it is not a change. > By rephrasing the definition this way, you give the "register" > storage-class more meaning. In particular, you open the > door to compilers that perform global optimizations using > the fact that "register" variables can never have their values > changed by indirection through a pointer. The compiler can > optimize the use of "register" variables because it can always > know when the register values are used and changed. Well, maybe. What about something of storage class "static" or "external" that is never aliased? Should "external register foo" be allowed? If it is, should the compiler actually try (somehow) to place it into a register? What about something that is a member of a structure or array? It may give the "register" storage class more meaning, but the meaning isn't what people think of when they think "register". If such a construct is truly necessary, some other keyword should be provided. I'm not convinced there aren't better ways of accomplishing this goal. > If we have > > enum E1 { e1 } var; > enum E2 { e2 }; > > is it legal to say > > var = e2; > > The answer is almost certainly yes...but we would be happy > if we were allowed to give a warning or an error message for > the operation, if there is no explicit cast. Similarly, we > would like to give a warning for things like > > var = e2 + 1; Yes. 100 votes for this. > On the other hand, it would be very convenient if one func- > tion could declare an object "const" while another did not. > This would let a function indicate when it did not intend to > change the value of an external object, and thereby allow > local optimizations. Presumably, an optimizing compiler can figure this out without the programmer's help. 1) "const" is supposed to be part of the type of an object, so that attempts to modify a "const" object can be detected at compile time. Allowing this sort of thing muddies the waters somewhat. 2) It might be tricky to implement with some loaders. > The last sentence of the Semantics section reads > > If the list is empty in a function declaration > that is part of a function definition, the func- > tion has no parameters. > > What does this say about a function definition like > > int (*F(int a))() {... > > Since the empty identifier list appears as part of a func- > tion definition, the function pointed to by F's return value > takes no arguments. This was probably not what they intended; presumably, the intent was that int foo() { ... } was to declare a function with no arguments. The term "part of" is poorly chosen; some more specific term should be used. (Or C++ should be used, where "int foo();" also declares a function with no arguments; unfortunately, this can't be changed in C. Yet.) > Can auto initializers make use of external variables > with the same name as the symbol being initialized? For > example, is the following valid? > > int i = 1; > f() { > char i = i * 2; > ... > > This sort of construction is allowed and used in Berkeley C > code. Where is this code used? Sounds like it should be cleaned up to me. This kind of construct is going to cause somebody to trip over it when reading code. > The Rationale states that a format for variable-length > argument lists was rejected because the functions > "vfprintf", etc. were "more controlled". This comment > confuses us, because we don't understand what "more > controlled" means. Very clearly, the "vfprintf" approach > offers less freedom and therefore is less useful. Can "%v" and the like be implemented on any system on which "vfprintf" can be implemented? If no, the "vfprintf" will be more widely available and is therefore more useful. > We suggest that "printf" and friends obtain a new > specifier "%v", which accepts two arguments: a new format > string and a "va_list" of items to format. This is similar > to the existing "%r" construct on UNIX systems. *Some* UNIX systems. It's not in 4.2BSD or System V, and it wasn't documented in V7 (I don't remember whether it was there or not). > It seems odd that "strncat" always adds a trailing '\0' > but "strncpy" does not. It may be considered odd, but that's the way UNIX works. Too late to change it now, unless you want to give the new function a different name. (I think the intent can best be described by discussing two character string types; null-terminated strings, and null-or-end-of-buffer-terminated strings. The latter appear, for example, in directories on UNIX systems using the V6 or V7 file systems, where a 14-character name has no null terminator. "strncpy" copies one null-or-end-of-buffer-terminated string to another, while "strncat" appends a null-or-end-of-buffer-terminated string to a null-terminated string. (If you want a version of "strncpy" that copies a null-or-end-of-buffer-terminated string to a null-terminated string, clear out the null-terminated string and "strcat" the other string to it.) > For greater uniformity, the name of this function > should be changed to "strpspn". This emphasizes the way it > parallels "strpbrk". For greater compatibility with existing UNIX implementations, the name of the function should be left as "strspn". This emphasizes the fact that it does the same thing as the UNIX function with that name. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)