🚀 go-pugleaf

In article <43t07j$q19@caip.rutgers.edu>, halasz@caip.rutgers.edu writes:
>There is a grave misunderstanding here: at no time in my part of this
>discussion referrd I to the use of f-p scope in generating right code,
>nor will I.  

I refer you to the following, which you posted recently.:

:  Consider the PDP-11: pointer to 'char' and
:pointer to 'int' need different-"shaped" pointers.  For generating
:right argument-passing code for it, the compiler needs to know which it
:is.

Another recent quote from you:
:I know not what you mean, but I see a problem in seeing hou to generate
:code for a pointer ere that which the pointer points to is known.

And another:
:That is, in the parameter-type 'struct S *' there is not enough
:pointer-typing information for the compiler to generate the right
:argument-passing code.

So, perhaps my misinderstanding is not totally inexplicable.

>I referrd to its use in rejecting source-code when a call
>entails passing a pointer about which not enough is known.  My examples
>bear onlie on that.  As for the grounds for seeking such behavior, I
>suggest the lack of that guarantee of safetie suppozedlie afforded by
>fullie declaring all parameters.
>
>But I hav thought of more examples, that this explanation explains not.
>There is nothing wrong with generating the same code for "j" and "js",
>and "k" and "ks",
>	struct
>	{	char l;
>	} js, *ks;
>	char j, *k;
>but another has posted that the standard requires "ks" to hav the same
>"shape" as this "fs":
>	struct
>	{	float m;
>	} *fs;
>.  That is, all 'struct'-pointers shall hav the same "shape".
>Therefore, the compiler has no pointer-code-trouble with this:
>	int k(struct S *);
>.  Furthermore, if the latter foregoind 'struct' is 'struct S', and the
>programmer passes a pointer to the former 'struct', the compiler, it seems,
>is permitted to generate code and warning, even though this can lead to
>bus error on processors that hav require stricter alignment for the latter
>than the former--and a cast makes the warning go awai.

I don't understand this. If you try passing a pointer to one kind of struct to
a function that accepts a pointer to a different kind of struct, the compiler
is *required* to issue a diagnostic. You complain that the compiler is
"permitted to generate code and warning". What you don't realize is that the
compiler is ALWAYS permitted to generate code and a warning, no matter how bad
your source code is. The Standard *requires* a diagnostic for this kind of
parameter mismatch, and that's the best the Standard can do.

>
>As for the older C, there is no safetie-guarantee in
>argument-passing.  Promotion is nothing more than a hack that
>makes not declaring the parameters slightlie safer.

Couldn't make sense of the above. Pointer types don't get "promoted" in old C.

>
>In article <43rqp8$6pc@rdsunx.crd.ge.com>, volpe@bart.crd.ge.com (Christopher R. Volpe) writes:
>> .... 
>> Of course, as I said before, f-p scope is useful for one thing: being able to
>> have header files with comprehensible prototypes like:
>> 
>> 	int foobar(int window, float color);
>> 
>> without corrupting the user's namespace with identifiers "window" and
>If that is so, it is no more than a bad hack, unless it also permits
>information-hiding, but C needs much more for that to work.

What is a bad hack? F-p scope? Perhaps. What's your solution that allows
declarations like the above without namespace corruption?

--

Chris Volpe				Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D			Fax:   (518) 387-6560
PO Box 8, Schenectady, NY 12301		Email: volpecr@crd.ge.com