Globals in different files, different types, same names 
Author Message
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Different value when converting into different type

2. compile different source files with different exception handling

3. Different resource files for different project settings???

4. Same EVC + Different PC's = arm exe DIFFERENT file size (iPAQ)

5. multiĆ¼ple classes with same name in different files

6. Getting name of PrinterDriver files for different version of Windows

7. Show 2 different files with same names?

8. problem with file input of different types

9. Different Data Types in a File

10. SDI-app with different file-types ???

11. Using types in a different assembly given that the type may be used or not used

12. Different sizes of long int on different machines.

 

 
Powered by phpBB® Forum Software