C Language, Globals in different files, different types, same names

Globals in different files, different types, same names

Author	Message
Paul Sor #1 / 25	Globals in different files, different types, same names Ok, to get down to the nitty gritty, File A.c char IniName[256]; . . . strcpy(IniName,"SomeName.ini"); BRead(IniName); . . File B.c . . . FILE IniName; . . . void BRead(char FileName) { . . . . . while(fgets(LineIn, AOINI_LINE_LENGTH, IniFile)); . . . Ok, what IniName is used were? I know what happens in M$VC, it always uses the char *. Is this correct? I would have thought that the FILE one would have taken precedence over the scope in file B. Anyway, is this just a peculiarity to M$, or do is this some other perversion? TIA Paul
Sun, 30 May 2004 03:28:38 GMT

Ben Pfaf #2 / 25	Globals in different files, different types, same names Quote: > Ok, to get down to the nitty gritty, > File A.c > char *IniName[256]; > File B.c > FILE IniName; This is an error that results in undefined behavior. You have declared variables with the same name but different types with external linkage. Rename one of them or give them internal linkage (by adding `static' to the declaration).
Sun, 30 May 2004 03:31:15 GMT

willem veenhove #3 / 25	Globals in different files, different types, same names Quote: > Ok, to get down to the nitty gritty, > File A.c > char IniName[256]; > strcpy(IniName,"SomeName.ini"); > BRead(IniName); First, make up your mind what kind of thing IniName is. Defined this way, it's an array of 256 char pointers without any memory for the strings attached to it, so you can't just strcpy something in it as you seem to believe ... Quote: > File B.c > FILE IniName; > void BRead(char FileName) > { > while(fgets(LineIn, AOINI_LINE_LENGTH, IniFile)); > Ok, what IniName is used were? > I know what happens in M$VC, it always uses the char *. IniName is not used at all in file b.c as far as I can see, so how do you know that the one in b.c is used by MSVC? Quote: > Anyway, is this just a peculiarity to M$, or do is this some > other perversion? If it's some another perversion, it yours ... willem
Sun, 30 May 2004 05:01:41 GMT

Paul Sor #4 / 25	Globals in different files, different types, same names Quote: > > Ok, to get down to the nitty gritty, > > File A.c > > char IniName[256]; > > File B.c > > FILE IniName; > This is an error that results in undefined behavior. You have > declared variables with the same name but different types with > external linkage. Rename one of them or give them internal > linkage (by adding `static' to the declaration). Ok, fair enough. The question is then raised, if I did this: File A.C char IniName[256]; File B.c static FILE IniName; would it be legal? Not to sound as though I am trying not to change names of the variable (I actually already have) the code in b.c is part of our common library, and this has raised an interesting point of what if this happens again. Also by using the static method, is this legal? File B.c static FILE SomeFile; File c.c extern File SomeFile; TIA Paul.
Sun, 30 May 2004 05:06:02 GMT

Ben Pfaf #5 / 25	Globals in different files, different types, same names Quote: > Ok, fair enough. The question is then raised, if I did this: > File A.C > char *IniName[256]; > File B.c > static FILE IniName; > would it be legal? Well, yes, as long as you didn't also declare the IniName with external linkage in the same file as the one with internal linkage. If you do that, it'll result in a compiler error, because you can't redeclare an object with a different type. Also, I forgot to mention this earlier: you're not supposed to declare objects of type FILE, only pointers to them. FILE is an opaque type. Quote: > Also by using the static method, is this legal? > File B.c > static FILE SomeFile; > File c.c > extern File SomeFile; Sure (if it were legitimate to declare objects of type FILE at all and if File is some type you've defined). Objects with internal linkage in different translation units don't interfere with one another.
Sun, 30 May 2004 05:11:59 GMT

willem veenhove #6 / 25	Globals in different files, different types, same names Quote: > > > File A.c > > > char IniName[256]; > > > File B.c > > > FILE IniName; > > This is an error that results in undefined behavior. You > > have declared variables with the same name but different > > types with external linkage. Rename one of them or give them > > internal linkage (by adding `static' to the declaration). > Ok, fair enough. The question is then raised, if I did this: > File A.C > char IniName[256]; still wrong ... Quote: > File B.c > static FILE IniName; Also wrong. You can't use a FILE object this way, whether it's static or not! Use FILE * instead ... Either learn to copy and paste correctly, or buy a good C book. willem
Sun, 30 May 2004 05:31:27 GMT

John Row #7 / 25	Globals in different files, different types, same names Quote: > Ok, to get down to the nitty gritty, > File A.c > char *IniName[256]; ^ > . > . > . > strcpy(IniName,"SomeName.ini"); I don't think your compiler will like this, even if it is a Microsoft one! John
Sun, 30 May 2004 07:29:17 GMT

Micah Cowa #8 / 25	Globals in different files, different types, same names Quote: > Also, I forgot to mention this earlier: you're not supposed to > declare objects of type FILE, only pointers to them. FILE is an > opaque type. To clarify (I hope) - there's nothing wrong per se with declaring an object of type FILE, it's just that, well, what can you do with it? How do you open it? fopen() opens a file and returns a pointer to the new file type. There's no way to copy the contents pointed at by this return value into your FILE variable, since you don't know whether it contains pointers to other things you don't know about. Micah -- Did you know that every time someone executes fflush(stdin), it causes a spammer to send out another spam? - Gordon Burditt
Sun, 30 May 2004 10:28:51 GMT

Ernst Rattenhub #9 / 25	Globals in different files, different types, same names says... Quote: >> Also, I forgot to mention this earlier: you're not supposed to >> declare objects of type FILE, only pointers to them. FILE is an >> opaque type. >To clarify (I hope) - there's nothing wrong per se with declaring an >object of type FILE, it's just that, well, what can you do with it? >How do you open it? fopen() opens a file and returns a pointer to the >new file type. There's no way to copy the contents pointed at by this >return value into your FILE variable, since you don't know whether it >contains pointers to other things you don't know about. >Micah I dare say it depends on what type of programming you're involved in. For example, if you're working on operating system code, there will be many occasions when you have to declare FILE objects; you'll damn well have to know exactly what the FILE type looks like in detail; and there will be lots of things you can do with it. Are you assuming that all C programming will be at a level where an operating system is already serving you and hiding the nitty-gritty details of what's going on? If so, that is an overly restrictive view in my opinion. In the final analysis, if there were never any reason to declare a FILE object anywhere, there would be no reason for a FILE type to exist at all. -- Ernst Rattenhuber
Mon, 31 May 2004 05:54:28 GMT

Ben Pfaf #10 / 25	Globals in different files, different types, same names Quote: > says... > >To clarify (I hope) - there's nothing wrong per se with declaring an > >object of type FILE, it's just that, well, what can you do with it? > >How do you open it? fopen() opens a file and returns a pointer to the > >new file type. There's no way to copy the contents pointed at by this > >return value into your FILE variable, since you don't know whether it > >contains pointers to other things you don't know about. > I dare say it depends on what type of programming you're involved in. > For example, if you're working on operating system code, there will > be many occasions when you have to declare FILE objects; you'll damn > well have to know exactly what the FILE type looks like in detail; > and there will be lots of things you can do with it. That's outside the scope of the C programming language. If you're writing code to implement these things, then you're invoking undefined behavior at some point anyhow, and there's nothing that the language standard can do to help you.
Mon, 31 May 2004 05:56:59 GMT

Ernst Rattenhub #11 / 25	Globals in different files, different types, same names Quote: >> says... >> >To clarify (I hope) - there's nothing wrong per se with declaring an >> >object of type FILE, it's just that, well, what can you do with it? >> >How do you open it? fopen() opens a file and returns a pointer to the >> >new file type. There's no way to copy the contents pointed at by this >> >return value into your FILE variable, since you don't know whether it >> >contains pointers to other things you don't know about. >> I dare say it depends on what type of programming you're involved in. >> For example, if you're working on operating system code, there will >> be many occasions when you have to declare FILE objects; you'll damn >> well have to know exactly what the FILE type looks like in detail; >> and there will be lots of things you can do with it. >That's outside the scope of the C programming language. If >you're writing code to implement these things, then you're >invoking undefined behavior at some point anyhow, and there's >nothing that the language standard can do to help you. I think you're putting things too strongly there. I don't see that I will necessarily need to invoke undefined behavior when programming OS code in C. Implementation-defined behavior - yes, definitely. Can you give an example of a situation where an OS programmer would _have_ to invoke undefined behavior? In any case, you told someone that you should never declare an object of type FILE. I still maintain that if that is the case, the type FILE can not possibly be needed. Actually I understand what you mean: in a typical "user" program, intended to run in a controlled environment with the support of a traditional operating system, you should not declare any objects of type FILE. But in that case, you should have made the limitations to your blanket statement clear. I sympathize with the efforts that regulars here make to keep the group on-topic, but in this case I think you're misdirected. OS programming does not really differ that much from regular programming. You may need to program certain parts of (for example) the low-level boot code in assembly language, and you will need to define many of the things that the C standard says are implementation-defined. I don't see how that is "outside the scope of the C language". Quite the opposite - the standard helps you by telling you what you need to define and what you should leave alone. I think that kind of C usage is very much on-topic, and a lot more interesting than many of the other things discussed ad nauseam here. -- Ernst Rattenhuber
Tue, 01 Jun 2004 08:09:06 GMT

Mark McIntyr #12 / 25	Globals in different files, different types, same names Quote: >Can you give an example of a situation where an OS programmer would >_have_ to invoke undefined behavior? Accessing any hardware, including disk drives, memory, CPU, IO ports, keyboard, mouse, screen etc. Multitasking, context switching, interrupt handling, security, networking, the list goes on !! -- Mark McIntyre CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
Tue, 01 Jun 2004 08:25:54 GMT

Richard Heathfiel #13 / 25	Globals in different files, different types, same names Quote: > >Can you give an example of a situation where an OS programmer would > >_have_ to invoke undefined behavior? > Accessing any hardware, including disk drives, memory, CPU, IO ports, > keyboard, mouse, screen etc. Multitasking, context switching, > interrupt handling, security, networking, the list goes on !! There's no reason why the implementation can't make the hardware accessible via the stdio interface, and some implementations do. Keyboard, screen, and disk drives are obvious examples. Less obvious is networking, memory, ... As for security, it depends what kind. There's no reason I can think of why you shouldn't be able to write, say, crypto software in strictly conforming C, or, at the worst, conforming-enough-for-clc C. :-) -- "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999. C FAQ: http://www.eskimo.com/~scs/C-faq/top.html K&R answers, C books, etc: http://users.powernet.co.uk/eton
Tue, 01 Jun 2004 17:07:12 GMT

Mark McIntyr #14 / 25	Globals in different files, different types, same names On Fri, 14 Dec 2001 09:07:12 +0000, Richard Heathfield Quote: >> >Can you give an example of a situation where an OS programmer would >> >_have_ to invoke undefined behavior? >> Accessing any hardware, including disk drives, memory, CPU, IO ports, >> keyboard, mouse, screen etc. Multitasking, context switching, >> interrupt handling, security, networking, the list goes on !! >There's no reason why the implementation can't make the hardware >accessible via the stdio interface, and some implementations do. Sure, but the quesiton was about OS programming. I'm not sure an OS can use standard C to address the H/W Quote: >Keyboard, screen, and disk drives are obvious examples. Less obvious is >networking, memory, ... >As for security, it depends what kind. There's no reason I can think of >why you shouldn't be able to write, say, crypto software in strictly >conforming C, or, at the worst, conforming-enough-for-clc C. :-) I was thinking more of something like NTFS or unix file permissions. Not sure how you'd do that in straight C. -- Mark McIntyre CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
Wed, 02 Jun 2004 06:18:57 GMT

Dan P #15 / 25	Globals in different files, different types, same names Quote: >> >Can you give an example of a situation where an OS programmer would >> >_have_ to invoke undefined behavior? >> Accessing any hardware, including disk drives, memory, CPU, IO ports, >> keyboard, mouse, screen etc. Multitasking, context switching, >> interrupt handling, security, networking, the list goes on !! >There's no reason why the implementation can't make the hardware >accessible via the stdio interface, and some implementations do. There is no stdio interface when you're implementing the OS. You're basically using a freestanding implementation in such cases. Dan -- Dan Pop CERN, IT Division Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Wed, 02 Jun 2004 08:21:26 GMT

Page 1 of 2

[ 25 post ]

Go to page: [1] [2]