Comments on proposed C standard

[Guy Harris]

>      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 at sun.com (or guy at sun.arpa)