ENV VAR addresses

A

Anonymous

Nick said:
not really. There are plenty of ways to write to stdout.
There's only one way to read an environmental variable
<pedantic> using the stanadrard library </pedantic>.

The OP made it clear that he isn't interested in using the
standard library on this occasion. If he had asked "What's
the best way to access an environment variable in a
reasonably portable manner?" my answer would have been
"Use getenv() - but please be aware that the C standard
leaves so much implementation-defined in this regard that,
depending on what exactly you're wanting to do and your
target audience, it's possible your net portability gain
over using a platform-specific solution isn't all that
great."

In fact, I think that, *practically* speaking, anything the
standard declares as implementation-defined may as well just
have been declared as undefined when it comes to *real-world*
programming in heterogeneous environments - the reason being
that if you have to look at a bunch of implementations'
documentation manuals anyway, you may as well use the best
implementation-specific solution in each case.

Yes, I think from now on I too will be a pedant and advise
against all programming that relies on implementation-defined
properties or behaviors for which you may have to check
implementation documentation. The first victim will be
fopen().

Yours,
Han from China
 
G

Guest

Nick Keighley wrote:
not really. There are plenty of ways to write to stdout.
There's only one way to read an environmental variable
<pedantic> using the [standard] library </pedantic>.

The OP made it clear that he isn't interested in using the
standard library on this occasion.

and I think he is making a mistake.

If he had asked "What's
the best way to access an environment variable in a
reasonably portable manner?" my answer would have been
"Use getenv()

oh good

- but please be aware that the C standard
leaves so much implementation-defined in this regard

I don't see a great deal of implementation defined behaviour for
getenv() in my copy of the standard. The list of environmental
variables is implementaion defined, but then I don't see how it could
be otherwise. We *want* the freedom to define new environmental
variables.

Yes, it's ID how you alter EVs but then taht isn't a problem for getenv
().

You are being intentionally obtuse.

that,
depending on what exactly you're wanting to do and your
target audience, it's possible your net portability gain
over using a platform-specific solution isn't all that
great."

cobblers.

getenv() provides a reasonably defined interface that is
portable across a wide range of platforms. The only deficency
I can see is the lack of a setenv(). But the OP seems
only to want "a more effiecient" way of reading EVs. How does he
know getenv() is too slow? Has he timed it?

In fact, I think that, *practically* speaking, anything the
standard declares as implementation-defined may as well just
have been declared as undefined when it comes to *real-world*
programming in heterogeneous environments

I disagree. I've ported things that used getenv() and other
standard library functions with minor cases of ID behaviour
without any great trouble (usually without *any* trouble).
- the reason being
that if you have to look at a bunch of implementations'
documentation manuals anyway, you may as well use the best
implementation-specific solution in each case.

I strongly disagree. I don't spend a great deal of time
speelunking manuals for ID behaviour. Many of the standard
library functions make enough guarantees to make this unneccessary,
You are creating work for yourself. Or rather I think
you are maliciously trying to create work for people foolish
enough to believe what you say.

Yes, I think from now on I too will be a pedant and advise
against all programming that relies on implementation-defined
properties or behaviors for which you may have to check
implementation documentation.

then you are a troll and an idiot. But I repeat myself.
The first victim will be fopen().

a perfect example of your idiocy. The last time I saw
a need to fool arounbd with implemtaion behaviour with fopen()
was on VMS. I suspect IBM mainframes may necessiate it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

ENV VAR addresses 0
ENV VAR addresses 4
ENV VAR addresses 1
ENV VAR addresses 2
ENV VAR addresses 2
ENV VAR addresses 1
ENV VAR addresses 2
ENV VAR addresses 0

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top