473,321 Members | 1,667 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,321 software developers and data experts.

please comment

As i am not at school for c programming can you please
tell me if there is anything bad about this program

/* EX4-9.C FUNCTION TO CALL OTHER FUNCTIONS */

#include<stdio.h>

float div(float a, float b);
float multi(float a, float b);
void call(void);

float a,b,c;
char z;

int main(void)
{

printf("Enter m to multiply or d to divid:");
scanf("%c",&z);
printf("Enter two numbers: ");
scanf("%f %f", &a, &b);

call();

return 0;
}
float div(float a, float b)
{
float c;

if(b == 0)
printf("The divisor should not be a zero\n");
else
c = a / b;
return c;
/* OR return(a / b); */
}

float multi(float a, float b)
{
int c;
return (c = a * b);
/* OR return(a * b); */
}

void call(void)
{

if(z == 'm')
c = multi(a,b);
else
c = div(a,b);

if(z != 'm' && z != 'd'){
c = 0;
printf("Incorrect operator\n");
}
printf("Output %f\n",c);

}
Nov 13 '05 #1
36 1610
amanayin wrote:
As i am not at school for c programming can you please
tell me if there is anything bad about this program

/* EX4-9.C FUNCTION TO CALL OTHER FUNCTIONS */

#include<stdio.h>

float div(float a, float b);
Unless you have a very good reason, such as using huge data sets,
you should use double instead of float. The few bytes you save
by using floats are not worth the trouble, and in many situations
the floats are converted to doubles anyway.
float multi(float a, float b);
void call(void);

float a,b,c;
char z;
Global variables should be avoided unless there is a very good
reason to use them. In this program, the use of globals is not
justified.
int main(void)
{

printf("Enter m to multiply or d to divid:");
scanf("%c",&z);
It is safer to use a combination of fgets and sscanf (or atof)
for interactive input. Suppose, for instance, that the user
typed in 'mm' instead of just 'm'. You should also check the
return value of scanf.
printf("Enter two numbers: ");
scanf("%f %f", &a, &b);

call();

return 0;
}
float div(float a, float b)
{
float c;

if(b == 0)
In general, one should not test floating point numbers for equality.
printf("The divisor should not be a zero\n");
else
c = a / b;
return c;
If b == 0, at this point c contains garbage.
/* OR return(a / b); */
Not if b == 0.
}

float multi(float a, float b)
{
int c;
c should be float or double.
return (c = a * b);
/* OR return(a * b); */
The alternative is preferable.
}

void call(void)
{

if(z == 'm')
c = multi(a,b);
else
c = div(a,b);
Here you call div if z is anything other than 'm'.
if(z != 'm' && z != 'd'){
c = 0;
printf("Incorrect operator\n");
}
This check should come earlier, or be made part of the if/else above.
printf("Output %f\n",c);

}


Nov 13 '05 #2


amanayin wrote:
As i am not at school for c programming can you please
tell me if there is anything bad about this program

<snip>

In addition to comments you already received:

Make the body of "call()" a switch for clarity (your bug where you call
"div()" even if "c" is not 'd' wouldn't have happened if you had a
switch I bet).

Return a success/fail indication from "call()" to "main()" so it can
likewise return success/fail to the OS.

Use more meaningful names for variables (e.g. "numerator" and
"denominator" in "div()" instead of "a" and "b", "result" instead of "c"
everywhere, "operand" instead of "z" everywhere).

Delcare variables one per-line for clairty (contrast what you might
think "char *a,b;" means with what it actually means - "char *a; char b;")

No big deal, but from main() you could return EXIT_SUCCESS or
EXIT_FAILURE instead of 0 or 1 - include stdlib.h if you want to use them.

Something to consider - how will you detect it and what will you do
about it if the result of your calculation in "multi()" overflows (i.e.
is larger than the maximum value that can be held by) the type "float"?
Right now you'll just charge ahead with the calulation and return a
value that may be less than either original number.

Regards,

Ed.


Nov 13 '05 #3
On Sun, 09 Nov 2003 12:19:37 -0500, T.M. Sommers wrote:
amanayin wrote:

float div(float a, float b)
{
float c;
The function will return more predictable results if you
#include <math.h> and then initialize c:

float c = INFINITY;

or

float c = HUGE_VALF;

if(b == 0)


In general, one should not test floating point numbers for equality.


I think this is a poor comment. It is true "in general". But in this
code a direct comparison to zero is the correct thing to do, so why
confuse the issue? It would be better, in my opinion, to compare against
an explicitly floating point value:

if (b == 0.0)
printf("The divisor should not be a zero\n");
else
c = a / b;
return c;


Nov 13 '05 #4
On Sun, 09 Nov 2003 13:52:12 -0500, in comp.lang.c , Sheldon Simms
<sh**********@yahoo.com> wrote:
On Sun, 09 Nov 2003 12:19:37 -0500, T.M. Sommers wrote:
if(b == 0)
In general, one should not test floating point numbers for equality.


I think this is a poor comment. It is true "in general". But in this
code a direct comparison to zero is the correct thing to do,


Why? b is user input. Who says the io routine stores zero to perfect
precision? What if the OP thinks that comparing to zero is always ok,
and then tries to do it when b is the result of a computation?

It would be better, in my opinion, to compare against
an explicitly floating point value:


FWIW, b is a float, so 0 is promoted before the comparison, using the
usual promotion rules.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #5
On Sun, 09 Nov 2003 21:13:23 +0000, Mark McIntyre wrote:
On Sun, 09 Nov 2003 13:52:12 -0500, in comp.lang.c , Sheldon Simms
<sh**********@yahoo.com> wrote:
On Sun, 09 Nov 2003 12:19:37 -0500, T.M. Sommers wrote:
if(b == 0)

In general, one should not test floating point numbers for equality.
I think this is a poor comment. It is true "in general". But in this
code a direct comparison to zero is the correct thing to do,


Why? b is user input. Who says the io routine stores zero to perfect
precision?


Good question. The only applicable requirement in the standard that I
find after a quick search is:

7.20.1.3:
5 If the subject sequence has the hexadecimal form and FLT_RADIX is a
power of 2, the value resulting from the conversion is correctly rounded.

Then as recommended practice there is:

7.20.1.3:
9 If the subject sequence has the decimal form and at most DECIMAL_DIG
(defined in <float.h>) significant digits, the result should be correctly
rounded.

Nevertheless, it seems to me than an implementation that failed to
convert 0.0 precisely into a floating point value with value exactly
zero would be broken unless it is ok for the implementation to not
be able to represent 0.0 exactly at all. I don't believe that is
ok, but I haven't been able to convince myself of it 100% in the
last 5 minutes.
What if the OP thinks that comparing to zero is always ok,
and then tries to do it when b is the result of a computation?


That would be a problem, but we have no evidence of that in the
OP's post.
It would be better, in my opinion, to compare against
an explicitly floating point value:


FWIW, b is a float, so 0 is promoted before the comparison, using the
usual promotion rules.


Obviously. I should have made it clear that I meant better style, not
"more correct".
Nov 13 '05 #6
Sheldon Simms <sh**********@yahoo.com> wrote in message news:<pa****************************@yahoo.com>...
....
amanayin wrote:

float div(float a, float b)
{
float c;

The function will return more predictable results if you
#include <math.h> and then initialize c:

float c = INFINITY;


ICBW, but I don't think INFINITY was required for <math.h> in C90.

or

float c = HUGE_VALF;


--
Peter
Nov 13 '05 #7
On Sun, 09 Nov 2003 17:34:44 -0800, Peter Nilsson wrote:
Sheldon Simms <sh**********@yahoo.com> wrote in message news:<pa****************************@yahoo.com>...
...
> amanayin wrote:
>>
>> float div(float a, float b)
>> {
>> float c;


The function will return more predictable results if you
#include <math.h> and then initialize c:

float c = INFINITY;


ICBW, but I don't think INFINITY was required for <math.h> in C90.

That may be true but the current standard is C99.

Personally I don't know if either of the two macros are required
in C90. I know that both are required in C99 and that HUGE_VALF
actually appears in <math.h> on my system (with the value 'Inf').

or

float c = HUGE_VALF;

Nov 13 '05 #8
Mark McIntyre <ma**********@spamcop.net> wrote:
On Sun, 09 Nov 2003 13:52:12 -0500, in comp.lang.c , Sheldon Simms
<sh**********@yahoo.com> wrote:
On Sun, 09 Nov 2003 12:19:37 -0500, T.M. Sommers wrote:
if(b == 0)

In general, one should not test floating point numbers for equality.


I think this is a poor comment. It is true "in general". But in this
code a direct comparison to zero is the correct thing to do,


Why? b is user input.


Because in context, that test is used to prevent division by zero. It
doesn't matter if you divide by user-entered-almost-zero. It is exactly
0.0 that you need to avoid dividing by, nothing else.

Richard
Nov 13 '05 #9
In <pa****************************@yahoo.com> Sheldon Simms <sh**********@yahoo.com> writes:
On Sun, 09 Nov 2003 12:19:37 -0500, T.M. Sommers wrote:
amanayin wrote:

float div(float a, float b)
{
float c;


The function will return more predictable results if you
#include <math.h> and then initialize c:

float c = INFINITY;

or

float c = HUGE_VALF;


Neither of them is part of the commonly implemented C standard.
Using them is a guaranteed recipe for portability headaches. And last
time I checked, this newsgroup was focused on portable C programming.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #10
In <pa****************************@yahoo.com> Sheldon Simms <sh**********@yahoo.com> writes:
On Sun, 09 Nov 2003 17:34:44 -0800, Peter Nilsson wrote:
Sheldon Simms <sh**********@yahoo.com> wrote in message news:<pa****************************@yahoo.com>...
...
> amanayin wrote:
>>
>> float div(float a, float b)
>> {
>> float c;

The function will return more predictable results if you
#include <math.h> and then initialize c:

float c = INFINITY;


ICBW, but I don't think INFINITY was required for <math.h> in C90.


That may be true but the current standard is C99.

Personally I don't know if either of the two macros are required
in C90. I know that both are required in C99 and that HUGE_VALF
actually appears in <math.h> on my system (with the value 'Inf').


Invoke your compiler in conforming mode and HUGE_VALF is gone from
<math.h> (or your implementation is broken).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #11
On Mon, 10 Nov 2003 09:59:09 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
Mark McIntyre <ma**********@spamcop.net> wrote:
On Sun, 09 Nov 2003 13:52:12 -0500, in comp.lang.c , Sheldon Simms
<sh**********@yahoo.com> wrote:
>On Sun, 09 Nov 2003 12:19:37 -0500, T.M. Sommers wrote:
>
>>> if(b == 0)
>>
>> In general, one should not test floating point numbers for equality.
>
>I think this is a poor comment. It is true "in general". But in this
>code a direct comparison to zero is the correct thing to do,


Why? b is user input.


Because in context, that test is used to prevent division by zero. It
doesn't matter if you divide by user-entered-almost-zero. It is exactly
0.0 that you need to avoid dividing by, nothing else.


Especially given that floats were being used, you can overflow the
result as well as div/0, even for relatively small values of b.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
Nov 13 '05 #12
Mark McIntyre <ma**********@spamcop.net> wrote:
On Mon, 10 Nov 2003 09:59:09 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
Mark McIntyre <ma**********@spamcop.net> wrote:
On Sun, 09 Nov 2003 13:52:12 -0500, in comp.lang.c , Sheldon Simms
<sh**********@yahoo.com> wrote:

>On Sun, 09 Nov 2003 12:19:37 -0500, T.M. Sommers wrote:
>
>>> if(b == 0)
>>
>> In general, one should not test floating point numbers for equality.
>
>I think this is a poor comment. It is true "in general". But in this
>code a direct comparison to zero is the correct thing to do,

Why? b is user input.


Because in context, that test is used to prevent division by zero. It
doesn't matter if you divide by user-entered-almost-zero. It is exactly
0.0 that you need to avoid dividing by, nothing else.


Especially given that floats were being used, you can overflow the
result as well as div/0, even for relatively small values of b.


Yes, but that can't be helped at all, unless you forbid all divisors
smaller than 1.0. After all, (0.9*FLT_MAX) / 0.8 overflows, as well.

Richard
Nov 13 '05 #13
On Mon, 10 Nov 2003 14:49:07 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
Mark McIntyre <ma**********@spamcop.net> wrote:
Especially given that floats were being used, you can overflow the
result as well as div/0, even for relatively small values of b.


Yes, but that can't be helped at all, unless you forbid all divisors
smaller than 1.0. After all, (0.9*FLT_MAX) / 0.8 overflows, as well.


Agreed. However IMO the dangerous floating point comparison renders
overflows more likely - user input is likely to be a smallish number,
dividing by something almost but not entirely unlike zero would
probably still dork out.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
Nov 13 '05 #14
On Mon, 10 Nov 2003 13:47:00 +0000, Dan Pop wrote:
In <pa****************************@yahoo.com> Sheldon Simms <sh**********@yahoo.com> writes:
On Sun, 09 Nov 2003 17:34:44 -0800, Peter Nilsson wrote:
Sheldon Simms <sh**********@yahoo.com> wrote in message news:<pa****************************@yahoo.com>...
...
> amanayin wrote:
>>
>> float div(float a, float b)
>> {
>> float c;

The function will return more predictable results if you
#include <math.h> and then initialize c:

float c = INFINITY;

ICBW, but I don't think INFINITY was required for <math.h> in C90.


That may be true but the current standard is C99.

Personally I don't know if either of the two macros are required
in C90. I know that both are required in C99 and that HUGE_VALF
actually appears in <math.h> on my system (with the value 'Inf').


Invoke your compiler in conforming mode and HUGE_VALF is gone from
<math.h> (or your implementation is broken).


Nope, still works:

[sheldon@wsxyz mcc]$ cat test.c
#include <math.h>
#include <stdio.h>

int main (void)
{
printf("%g\n", HUGE_VALF);
return 0;
}
[sheldon@wsxyz mcc]$ gcc -Wall -W -O2 -std=c99 -pedantic test.c
[sheldon@wsxyz mcc]$ ./a.out
inf
[sheldon@wsxyz mcc]$
Nov 13 '05 #15
av
hi all,

T.M.Sommers mentioned "Unless you have a very good reason, such as
using huge data sets, you should use double instead of float". But
when i used double, i didnt get the result. for eg., when i multiply 2
by 3 my answer was 64.

Another doubt i have is
1. how do i find if my code is efficient and meets the performance
requirements.?
2. what is the necessity for setting value to INFINITY && HUGE_VALF ?

my code is as follows:

/* header files */
#include <stdio.h>
#include <stdlib.h>
#include <float.h>

/* function declarations */
double div(double num, double den);
double multi(double num1, double num2);

/* function main() */
int main(void)
{
// charater declaration
char choice;

// double declaration
double mulAns; // variable to store multiplication
answer
double divAns; // variable to store division answer
double num1, num2;
// function code
system("clear"); // clears the screen
printf(" Enter 'm' to Multiply or 'D' to Divide :");
scanf("%c",&choice);

if(choice=='m' || choice=='M')
{
printf("\n Enter 2 Numbers :");
scanf("%f %f",&num1,&num2);
mulAns= multi(num1,num2);
printf("\n Multiplication Answer : %f",mulAns);
printf("\n");
}
else if(choice=='d' || choice=='D')
{
printf("\n Enter Numerator && Denominator :");
scanf("%f %f",&num1, &num2);
divAns=div(num1,num2);
printf("\n Division Answer : %f",divAns);
printf("\n");
}
else if(choice !='m' || choice!='M' || choice!='d'||
choice!='D')
{
printf("\n Wrong Choice");
printf("\n");
return 1;
exit(1); // exit with failure
}

// function code ends here
return 0;
exit(0); // exit with Success
}

// function multi
double multi(double num1,double num2)
{
// double declarations
double answer;

// function code starts here
// if any 1 of the input number is zero, answer is
zero
if (num2==0.0 || num1==0.0)
{
answer=0.0;
return answer;
}
else
{
answer=num1 * num2;
return answer;
}
}

// function div
double div(double num, double den)
{
// float declarations
double answer;

// function code starts here
// if denominator is zero, the answer is zero
if(den==0.0)
{
answer=0.0;
return answer;
}
else
{
answer=num/den;
return answer;
}
}

thank you,
amsa.
ai***@acay.com.au (Peter Nilsson) wrote in message news:<63**************************@posting.google. com>...
Sheldon Simms <sh**********@yahoo.com> wrote in message news:<pa****************************@yahoo.com>...
...
amanayin wrote:
>
> float div(float a, float b)
> {
> float c;


The function will return more predictable results if you
#include <math.h> and then initialize c:

float c = INFINITY;


ICBW, but I don't think INFINITY was required for <math.h> in C90.

or

float c = HUGE_VALF;

Nov 13 '05 #16
On Mon, 10 Nov 2003 13:10:38 -0500, in comp.lang.c , Sheldon Simms
<sh**********@yahoo.com> wrote:
On Mon, 10 Nov 2003 13:47:00 +0000, Dan Pop wrote:
Personally I don't know if either of the two macros are required
in C90. I know that both are required in C99 and that HUGE_VALF
actually appears in <math.h> on my system (with the value 'Inf').
Invoke your compiler in conforming mode and HUGE_VALF is gone from
<math.h> (or your implementation is broken).


Incorrect - AFAIR an implementation is not broken because it accepts
nonstandard macros, even if in maximum conformance mode. If this were
the case, then user code would be uncompilable.

What an implementation may /not/ do in conforming mode is refuse to
accept Standard macros, or give a nonstandard meaning to them.
Nope, still works:


Probably because your implementation is the one whose writers lobbied
for HUGE_VALx to be added to the Standard :-)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
Nov 13 '05 #17
On 10 Nov 2003 13:54:02 -0800, in comp.lang.c , ae******@emich.edu
(av) wrote:
hi all,

T.M.Sommers mentioned "Unless you have a very good reason, such as
using huge data sets, you should use double instead of float". But
when i used double, i didnt get the result. for eg., when i multiply 2
by 3 my answer was 64.
Actually, it could also have printed 0, or a zillion, or -nan or
"hello sailor".

You need to check on the correct format specifiers for printf for
printing doubles, and for scanf for reading them. Top hint: they're
NOT the same, and at least one of them is wrong in your sample code.

Also, don't use div() as a function name - its a reserved word in C as
its the name of a function in math.h
Another doubt i have is
1. how do i find if my code is efficient and meets the performance
requirements.?
Run it a million times, time it and see if its fast enough. Seriously.
2. what is the necessity for setting value to INFINITY && HUGE_VALF ?


c is a local variable, so it is not initialised to anything sensible.
If the scanf failed (eg the user typed something invalid) then c would
be left indeterminate, and your code could behave peculiarly - for
example it has a 4 in 256 chance of actually executing, even though
the user typed in "x" or "111" or just hit the enter key.

Note that you will probably never see this when debugging - most
debuggers zero all local variables, for some reason. So this will only
happen when you run it for your teacher... :-(

..
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
Nov 13 '05 #18
On Mon, 10 Nov 2003 21:57:35 +0000, Mark McIntyre wrote:
On Mon, 10 Nov 2003 13:10:38 -0500, in comp.lang.c , Sheldon Simms
<sh**********@yahoo.com> wrote:
On Mon, 10 Nov 2003 13:47:00 +0000, Dan Pop wrote:
Personally I don't know if either of the two macros are required
in C90. I know that both are required in C99 and that HUGE_VALF
actually appears in <math.h> on my system (with the value 'Inf').

Invoke your compiler in conforming mode and HUGE_VALF is gone from
<math.h> (or your implementation is broken).


Incorrect - AFAIR an implementation is not broken because it accepts
nonstandard macros, even if in maximum conformance mode. If this were
the case, then user code would be uncompilable.


More importantly, HUGE_VALF *is* actually a standard macro, so when
I compile with the flag "-std=c99" and it works, this is only to
be expected.

As an aside, if I compile with "-std=c89", HUGE_VALF is not recognized
as a valid macro, and if I compile with "-traditional" then the keyword
'const' isn't recognized. But since C99 is the current standard, these
bits of trivia are uninteresting, IMO.
Nov 13 '05 #19
Sheldon Simms <sh**********@yahoo.com> writes:
On Mon, 10 Nov 2003 21:57:35 +0000, Mark McIntyre wrote:
On Mon, 10 Nov 2003 13:10:38 -0500, in comp.lang.c , Sheldon Simms
<sh**********@yahoo.com> wrote:
On Mon, 10 Nov 2003 13:47:00 +0000, Dan Pop wrote:

>Personally I don't know if either of the two macros are required
>in C90. I know that both are required in C99 and that HUGE_VALF
>actually appears in <math.h> on my system (with the value 'Inf').

Invoke your compiler in conforming mode and HUGE_VALF is gone from
<math.h> (or your implementation is broken).


Incorrect - AFAIR an implementation is not broken because it accepts
nonstandard macros, even if in maximum conformance mode. If this were
the case, then user code would be uncompilable.


More importantly, HUGE_VALF *is* actually a standard macro, so when
I compile with the flag "-std=c99" and it works, this is only to
be expected.

As an aside, if I compile with "-std=c89", HUGE_VALF is not recognized
as a valid macro, and if I compile with "-traditional" then the keyword
'const' isn't recognized. But since C99 is the current standard, these
bits of trivia are uninteresting, IMO.


Dan Pop's point, I think, is that the C99 standard is not yet widely
implemented, and code that depends on it is therefore non-portable and
not suitable for discussion in this newsgroup. Dan, please correct me
if I've misrepresented your position.

It's true that HUGE_VALF is required in C99; it may also be provided
(in a non-conforming mode) by some C90 implementations that have added
partial C99 support.

It's also true that a strict C90 compiler, invoked in conforming mode,
is not allowed to declare a HUGE_VALF macro in <math.h>. Otherwise
it would reject the following strictly conforming C90 program:

#include <math.h>
int main (void)
{
int HUGE_VALF;
return 0;
}

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Nov 13 '05 #20
On Tue, 11 Nov 2003 04:09:25 +0000, Keith Thompson wrote:
Sheldon Simms <sh**********@yahoo.com> writes:
On Mon, 10 Nov 2003 21:57:35 +0000, Mark McIntyre wrote:
> On Mon, 10 Nov 2003 13:10:38 -0500, in comp.lang.c , Sheldon Simms
> <sh**********@yahoo.com> wrote:
>
>>On Mon, 10 Nov 2003 13:47:00 +0000, Dan Pop wrote:
>>
>>>>Personally I don't know if either of the two macros are required
>>>>in C90. I know that both are required in C99 and that HUGE_VALF
>>>>actually appears in <math.h> on my system (with the value 'Inf').
>>>
>>> Invoke your compiler in conforming mode and HUGE_VALF is gone from
>>> <math.h> (or your implementation is broken).
>
> Incorrect - AFAIR an implementation is not broken because it accepts
> nonstandard macros, even if in maximum conformance mode. If this were
> the case, then user code would be uncompilable.


More importantly, HUGE_VALF *is* actually a standard macro, so when
I compile with the flag "-std=c99" and it works, this is only to
be expected.

As an aside, if I compile with "-std=c89", HUGE_VALF is not recognized
as a valid macro, and if I compile with "-traditional" then the keyword
'const' isn't recognized. But since C99 is the current standard, these
bits of trivia are uninteresting, IMO.


Dan Pop's point, I think, is that the C99 standard is not yet widely
implemented, and code that depends on it is therefore non-portable and
not suitable for discussion in this newsgroup.


So that would mean that ISO Standard C is off topic in comp.lang.c.
That is an interesting point of view.
Nov 13 '05 #21
Sheldon Simms <sh**********@yahoo.com> writes:
On Tue, 11 Nov 2003 04:09:25 +0000, Keith Thompson wrote:

[...]
Dan Pop's point, I think, is that the C99 standard is not yet widely
implemented, and code that depends on it is therefore non-portable and
not suitable for discussion in this newsgroup.


So that would mean that ISO Standard C is off topic in comp.lang.c.
That is an interesting point of view.


It's entirely possible that I've overstated his position; please don't
judge his words by my interpretation of them.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Nov 13 '05 #22
In <pa****************************@yahoo.com> Sheldon Simms <sh**********@yahoo.com> writes:
On Mon, 10 Nov 2003 21:57:35 +0000, Mark McIntyre wrote:
On Mon, 10 Nov 2003 13:10:38 -0500, in comp.lang.c , Sheldon Simms
<sh**********@yahoo.com> wrote:
On Mon, 10 Nov 2003 13:47:00 +0000, Dan Pop wrote:

>Personally I don't know if either of the two macros are required
>in C90. I know that both are required in C99 and that HUGE_VALF
>actually appears in <math.h> on my system (with the value 'Inf').

Invoke your compiler in conforming mode and HUGE_VALF is gone from
<math.h> (or your implementation is broken).
Incorrect - AFAIR an implementation is not broken because it accepts
nonstandard macros, even if in maximum conformance mode. If this were
the case, then user code would be uncompilable.


Our resident idiot strikes again. It's not a matter of accepting
nonstandard macros, it's a matter of defining them in the standard
headers.
More importantly, HUGE_VALF *is* actually a standard macro, so when
I compile with the flag "-std=c99" and it works, this is only to
be expected.

As an aside, if I compile with "-std=c89", HUGE_VALF is not recognized
as a valid macro, and if I compile with "-traditional" then the keyword
'const' isn't recognized. But since C99 is the current standard, these
bits of trivia are uninteresting, IMO.


C99 may be the current standard, but the conforming C99 are few and
far between. And gcc is NOT a conforming C99 compiler, no matter how
you invoke it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #23
In <pa***************************@yahoo.com> Sheldon Simms <sh**********@yahoo.com> writes:
On Mon, 10 Nov 2003 13:47:00 +0000, Dan Pop wrote:
In <pa****************************@yahoo.com> Sheldon Simms <sh**********@yahoo.com> writes:
On Sun, 09 Nov 2003 17:34:44 -0800, Peter Nilsson wrote:

Sheldon Simms <sh**********@yahoo.com> wrote in message news:<pa****************************@yahoo.com>...
...
> > amanayin wrote:
> >>
> >> float div(float a, float b)
> >> {
> >> float c;
>
> The function will return more predictable results if you
> #include <math.h> and then initialize c:
>
> float c = INFINITY;

ICBW, but I don't think INFINITY was required for <math.h> in C90.

That may be true but the current standard is C99.

Personally I don't know if either of the two macros are required
in C90. I know that both are required in C99 and that HUGE_VALF
actually appears in <math.h> on my system (with the value 'Inf').


Invoke your compiler in conforming mode and HUGE_VALF is gone from
<math.h> (or your implementation is broken).


Nope, still works:

[sheldon@wsxyz mcc]$ cat test.c
#include <math.h>
#include <stdio.h>

int main (void)
{
printf("%g\n", HUGE_VALF);
return 0;
}
[sheldon@wsxyz mcc]$ gcc -Wall -W -O2 -std=c99 -pedantic test.c


To what C standard does gcc conform when using the -std=c99 option?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #24
In <ks************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Sheldon Simms <sh**********@yahoo.com> writes:
On Tue, 11 Nov 2003 04:09:25 +0000, Keith Thompson wrote:

[...]
> Dan Pop's point, I think, is that the C99 standard is not yet widely
> implemented, and code that depends on it is therefore non-portable and
> not suitable for discussion in this newsgroup.


So that would mean that ISO Standard C is off topic in comp.lang.c.
That is an interesting point of view.


It's entirely possible that I've overstated his position; please don't
judge his words by my interpretation of them.


My position is that C89 hosted implementations are the *default* for this
newsgroup, and hence C89/C90 is the *default* standard for this newsgroup.
The reasons should be obvious. When someone wants to talk about C99,
this should be explicitly mentioned, just as in the case of K&R C or
freestanding implementations.

Therefore, it is *unacceptable* to post C99 solutions without *explicitly*
qualifying them as such. There is no point in confusing the people who
are not intimately familiar with the various C standards.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #25
On Tue, 11 Nov 2003 14:27:17 +0000, Dan Pop wrote:
In <pa***************************@yahoo.com> Sheldon Simms <sh**********@yahoo.com> writes:
On Mon, 10 Nov 2003 13:47:00 +0000, Dan Pop wrote:
In <pa****************************@yahoo.com> Sheldon Simms <sh**********@yahoo.com> writes:

On Sun, 09 Nov 2003 17:34:44 -0800, Peter Nilsson wrote:

> Sheldon Simms <sh**********@yahoo.com> wrote in message news:<pa****************************@yahoo.com>...
> ...
>> > amanayin wrote:
>> >>
>> >> float div(float a, float b)
>> >> {
>> >> float c;
>>
>> The function will return more predictable results if you
>> #include <math.h> and then initialize c:
>>
>> float c = INFINITY;
>
> ICBW, but I don't think INFINITY was required for <math.h> in C90.

That may be true but the current standard is C99.

Personally I don't know if either of the two macros are required
in C90. I know that both are required in C99 and that HUGE_VALF
actually appears in <math.h> on my system (with the value 'Inf').

Invoke your compiler in conforming mode and HUGE_VALF is gone from
<math.h> (or your implementation is broken).


Nope, still works:

[sheldon@wsxyz mcc]$ cat test.c
#include <math.h>
#include <stdio.h>

int main (void)
{
printf("%g\n", HUGE_VALF);
return 0;
}
[sheldon@wsxyz mcc]$ gcc -Wall -W -O2 -std=c99 -pedantic test.c


To what C standard does gcc conform when using the -std=c99 option?


None. However it is being invoked with an option to "determine the
language standard". Whether it actually conforms to C99 is beside the
point anyway. Would it make any difference if I bought a C99 compiler?

Nov 13 '05 #26
On Tue, 11 Nov 2003 14:42:28 +0000, Dan Pop wrote:
In <ks************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Sheldon Simms <sh**********@yahoo.com> writes:
On Tue, 11 Nov 2003 04:09:25 +0000, Keith Thompson wrote:

[...]
> Dan Pop's point, I think, is that the C99 standard is not yet widely
> implemented, and code that depends on it is therefore non-portable and
> not suitable for discussion in this newsgroup.

So that would mean that ISO Standard C is off topic in comp.lang.c.
That is an interesting point of view.


It's entirely possible that I've overstated his position; please don't
judge his words by my interpretation of them.


My position is that C89 hosted implementations are the *default* for this
newsgroup, and hence C89/C90 is the *default* standard for this newsgroup.
The reasons should be obvious. When someone wants to talk about C99,
this should be explicitly mentioned, just as in the case of K&R C or
freestanding implementations.

Therefore, it is *unacceptable* to post C99 solutions without *explicitly*
qualifying them as such. There is no point in confusing the people who
are not intimately familiar with the various C standards.


Thanks for your opinion, Mr. President of comp.lang.c. I respectfully
disagree that the current ISO standard for C is a second class standard in
this group.

Nov 13 '05 #27
In <pa****************************@yahoo.com> Sheldon Simms <sh**********@yahoo.com> writes:
On Tue, 11 Nov 2003 14:27:17 +0000, Dan Pop wrote:
In <pa***************************@yahoo.com> Sheldon Simms <sh**********@yahoo.com> writes:
[sheldon@wsxyz mcc]$ gcc -Wall -W -O2 -std=c99 -pedantic test.c
To what C standard does gcc conform when using the -std=c99 option?


None.


So, you have to invoke gcc in non-conforming mode to get the desired
behaviour. Precisely my point!
However it is being invoked with an option to "determine the
language standard". Whether it actually conforms to C99 is beside the
point anyway.
It is entirely the point!
Would it make any difference if I bought a C99 compiler?


It would make a difference if the usual C implementations used by the
average C programmer had a C99-conforming mode. Until then, C99 is
the default in comp.std.c and C89/C90 in comp.lang.c. Regardless of
your personal opinions.

This newsgroup is supposed to actually help people and giving them
advice that require "exotic" implementations without mentioning it
explicitly is far from being helpful. Then again, you may have a
different agenda than the rest of us...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #28
On Tue, 11 Nov 2003 04:09:25 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
>>On Mon, 10 Nov 2003 13:47:00 +0000, Dan Pop wrote:
>>
>>>
>>> Invoke your compiler in conforming mode and HUGE_VALF is gone from
>>> <math.h> (or your implementation is broken).
(I wrote) > Incorrect - AFAIR an implementation is not broken because it accepts
> nonstandard macros, even if in maximum conformance mode. If this were
> the case, then user code would be uncompilable.


Dan Pop's point, I think, is that the C99 standard is not yet widely
implemented, and code that depends on it is therefore non-portable and
not suitable for discussion in this newsgroup.


If that was Dan's point, he misexpressed it. His quoted comment above
reads to me as "if your compiler still has a definition of HUGE_VALF
when in conforming mode, then its broken". AFAIK this is not strictly
true - a compiler could have any number of private definitions in
scope even in the most conforming mode it has.
It's true that HUGE_VALF is required in C99; it may also be provided
(in a non-conforming mode) by some C90 implementations that have added
partial C99 support.

It's also true that a strict C90 compiler, invoked in conforming mode,
is not allowed to declare a HUGE_VALF macro in <math.h>.


In /strictly/ conforming mode, perhaps, if by strictly conforming you
mean a mode which implements only that which is defined in the
standard and no more.

However we've frequently discussed the utility and even the existence
of strictly conforming mode before, and I believe Dan has been a
strong advocate of its uselessness and irrelevance. My own opinion is
that no such mode exists - the standard is prescriptive not
proscriptive for the most part.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
Nov 13 '05 #29
On Tue, 11 Nov 2003 18:18:25 +0000, Dan Pop wrote:
This newsgroup is supposed to actually help people and giving them
advice that require "exotic" implementations without mentioning it
explicitly is far from being helpful.
I am sorry. I abase myself. I will never again suggest the use of a
Standard C feature that happens to be implemented in an "exotic"
implementation such as GCC.
Then again, you may have a different agenda than the rest of us...


Yes, my agenda has been to confuse people by encouraging the use of
standard C features, even though they are not available in non-"exotic"
implementations. How did you know?
Nov 13 '05 #30
Mark McIntyre <ma**********@spamcop.net> writes:
On Tue, 11 Nov 2003 04:09:25 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

[...]
It's true that HUGE_VALF is required in C99; it may also be provided
(in a non-conforming mode) by some C90 implementations that have added
partial C99 support.

It's also true that a strict C90 compiler, invoked in conforming mode,
is not allowed to declare a HUGE_VALF macro in <math.h>.


In /strictly/ conforming mode, perhaps, if by strictly conforming you
mean a mode which implements only that which is defined in the
standard and no more.

However we've frequently discussed the utility and even the existence
of strictly conforming mode before, and I believe Dan has been a
strong advocate of its uselessness and irrelevance. My own opinion is
that no such mode exists - the standard is prescriptive not
proscriptive for the most part.


There's an excellent reason *not* to declare user-space identifiers as
macros in standard headers. If any identifier I want to use in my
program might be declared as a macro, how can I write reasonably
portable code?

I used a strictly conforming program as my example to emphasize the
point. More generally, the point is that if an identifier FOO is not
reserved, I should be able to use it in my code.

BTW, I don't think there's such a thing as "strictly conforming mode";
the term "strictly conforming" applies to programs, not to
implementations.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Nov 13 '05 #31
On Wed, 12 Nov 2003 01:57:58 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
I used a strictly conforming program as my example to emphasize the
point.
But /was/ it strictly conforming? I'm just asking.
More generally, the point is that if an identifier FOO is not
reserved, I should be able to use it in my code.
I guess my point was that C89 didn't reserve identifiers beginning
with capital H for future library direction did it?
BTW, I don't think there's such a thing as "strictly conforming mode";
the term "strictly conforming" applies to programs, not to
implementations.


Absolutely. Which is partly why I reckon its meaningless to claim that
an implementation is "broken" if in "conforming mode" it doesn't or
indeed does do something or other. A
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
Nov 13 '05 #32
Mark McIntyre <ma**********@spamcop.net> writes:
On Wed, 12 Nov 2003 01:57:58 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
I used a strictly conforming program as my example to emphasize the
point.


But /was/ it strictly conforming? I'm just asking.


I believe so. It was certainly intended to be.

Here's the program I posted:

#include <math.h>
int main (void)
{
int HUGE_VALF;
return 0;
}

I believe this is a strictly conforming C90 program, but not a
strictly conforming C99 program (because C99's <math.h> declares
HUGE_VALF as a macro).
More generally, the point is that if an identifier FOO is not
reserved, I should be able to use it in my code.


I guess my point was that C89 didn't reserve identifiers beginning
with capital H for future library direction did it?


No, it didn't, and yes, there are things in C99 that break strictly
conforming C90 programs. I think many things in C99 were compromises
between strict upward compatibility and esthetics. The _Bool keyword
avoids intruding on the user's name space, but surely if it had been
added to C in the beginning it would have been spelled bool.

In the case of HUGE_VALF (and HUGE_VALL), I think the committee
decided that making it look consistent with the existing HUGE_VAL was
more important than strict compatibility. Probably few, if any,
existing programs used HUGE_VALF as an identifier (unlike the fairly
common use of "bool"), and such uses are fairly easy to identify.
BTW, I don't think there's such a thing as "strictly conforming mode";
the term "strictly conforming" applies to programs, not to
implementations.


Absolutely. Which is partly why I reckon its meaningless to claim that
an implementation is "broken" if in "conforming mode" it doesn't or
indeed does do something or other.


I don't follow your reasoning. If a C90 implementation (in
"conforming mode") doesn't properly handle a strictly conforming
program, it's broken, and it's likely to mishandle a lot of real-life
programs as well. If we don't require at least that much conformance
among C implementations, we might as well not have a standard. On the
other hand, if a C90 implementation's only non-conformities are
attempts to implement C99 features, like adding HUGE_VALF to <math.h>,
I'm inclined to cut it a little slack. On the other other hand,
unless it implements all of C99, it should probably have a way to turn
off the C99 features.

There are some incompatible changes introduced by new standards, but
that only happens once a decade or so, and it's usually not too
difficult to work around the changes. If I were an absolute purist,
I'd insist on _HUGE_VALF, _Restricte, _Inline, and so forth, and all
valid C90 programs would be valid C99 programs with the same
semantics. But I'm not.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Nov 13 '05 #33
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Mark McIntyre <ma**********@spamcop.net> writes:
On Wed, 12 Nov 2003 01:57:58 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
>I used a strictly conforming program as my example to emphasize the
>point.


But /was/ it strictly conforming? I'm just asking.


I believe so. It was certainly intended to be.

Here's the program I posted:

#include <math.h>
int main (void)
{
int HUGE_VALF;
return 0;
}

I believe this is a strictly conforming C90 program, but not a
strictly conforming C99 program (because C99's <math.h> declares
HUGE_VALF as a macro).


Warning: you're arguing with the comp.lang.c's resident idiot.
Mark McIntyre is immune to any kind of rational argument and he has
proven it many times.

Feel free to waste your time, but you have been warned...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #34
On Thu, 13 Nov 2003 02:56:09 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
Mark McIntyre <ma**********@spamcop.net> writes:
On Wed, 12 Nov 2003 01:57:58 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
>I used a strictly conforming program as my example to emphasize the
>point.


But /was/ it strictly conforming? I'm just asking.


I believe so. It was certainly intended to be.


<nitpick level=99>
Hmm. "strictly conforming". According to the standard, it shall use
only those features of the language and library specified in the
Standard.
I could therefore claim that since HUGE_VALF is not specified in the
Standard, its not a strictly conforming program.
</nitpick>
>BTW, I don't think there's such a thing as "strictly conforming mode";
>the term "strictly conforming" applies to programs, not to
>implementations.


Absolutely. Which is partly why I reckon its meaningless to claim that
an implementation is "broken" if in "conforming mode" it doesn't or
indeed does do something or other.


I don't follow your reasoning. If a C90 implementation (in
"conforming mode") doesn't properly handle a strictly conforming
program, it's broken.


Err.....
But if, as you yourself say in the retained quote above, there's no
such thing as strictly conforming mode, then how can it be in it?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
Nov 13 '05 #35
Mark McIntyre wrote:
On Thu, 13 Nov 2003 02:56:09 GMT, in comp.lang.c , Keith Thompson

I believe so. It was certainly intended to be.

<nitpick level=99>
Hmm. "strictly conforming". According to the standard, it shall use
only those features of the language and library specified in the
Standard.
I could therefore claim that since HUGE_VALF is not specified in the
Standard, its not a strictly conforming program.


So you are saying that it is impossible to write a strictly
conforming program.

The program, which you snipped, was strictly conforming to C90. Just
to make that clear (and it was clear).
I don't follow your reasoning. If a C90 implementation (in
"conforming mode") doesn't properly handle a strictly conforming
program, it's broken.


Err.....
But if, as you yourself say in the retained quote above, there's no
such thing as strictly conforming mode, then how can it be in it?


Because the standard defines what a strictly conforming program is...
Maybe you should read the paragraph again, there is never any mention
of strictly conforming mode.

--
Thomas.
Nov 13 '05 #36
Mark McIntyre <ma**********@spamcop.net> writes:
On Thu, 13 Nov 2003 02:56:09 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
Mark McIntyre <ma**********@spamcop.net> writes:
On Wed, 12 Nov 2003 01:57:58 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
>I used a strictly conforming program as my example to emphasize the
>point.

But /was/ it strictly conforming? I'm just asking.


I believe so. It was certainly intended to be.


<nitpick level=99>
Hmm. "strictly conforming". According to the standard, it shall use
only those features of the language and library specified in the
Standard.
I could therefore claim that since HUGE_VALF is not specified in the
Standard, its not a strictly conforming program.
</nitpick>


Huh? The program I posted doesn't use HUGE_VALF, the macro declared
in C99's <math.h>; it simply uses HUGE_VALF as an identifier. As I
already said, it's a strictly conforming C90 program, but not a
strictly conforming C99 program.
>BTW, I don't think there's such a thing as "strictly conforming mode";
>the term "strictly conforming" applies to programs, not to
>implementations.

Absolutely. Which is partly why I reckon its meaningless to claim that
an implementation is "broken" if in "conforming mode" it doesn't or
indeed does do something or other.


I don't follow your reasoning. If a C90 implementation (in
"conforming mode") doesn't properly handle a strictly conforming
program, it's broken.


Err.....
But if, as you yourself say in the retained quote above, there's no
such thing as strictly conforming mode, then how can it be in it?


I never used the phrase "strictly conforming mode", just "conforming
mode".

The term "conforming mode" (referring to an implementation) doesn't
actually appear in the standard, but it's common for an actual
implementation to provide some kind of mode (e.g., a set of
command-line options) intended to cause it to be a conforming
implementation. The phrase I used,
a C90 implementation (in "conforming mode")
is what the standard calls simply a "conforming implementation".

The C90 vs. C99 stuff is really a side issue. The point is that a
conforming implementation cannot declare, in a standard header, any
identifier not specified in the standard or reserved for the
implementation if it will interfere with a program's use of that
identifier. An implementation that declares FOO as a macro in
<math.h> is probably not conforming, because it can interfere with a
valid program that uses FOO as an identifier.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Nov 13 '05 #37

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: gene.ellis | last post by:
Hello everyone. Put very simply, I need to have the ability to write to open a .txt file, write to it, and then close it. I know how to do this, but the part I am not sure how to accomplish is that...
5
by: gene.ellis | last post by:
Hello everyone, I am really having a lot of trouble understanding the DOM and I doing something quite basic. I need to the DOM (in PHP 5) to modify an XML file. For example the XML basically...
1
by: MultiTaskinG | last post by:
I want to retrieve all comment stored from my web users ordered BY THREAD and BY TIMESTAMP (INT 11) with a single query (if is possible) now I launch this query: SELECT thread, timestamp,...
18
by: spiffo | last post by:
The Main Issue in a nutshell I am a corporate developer, working for a single company. Got a new project coming up and wondering if I should stay with Python for this new, fairly large project,...
2
by: Sathyaish | last post by:
I am writing a program that will take a string that has a C source file and it would format all the multi-line comments like these: //Jingle bells, jingle bells, jingles all the way //O what...
1
by: Mark Hollander | last post by:
Hi All, Could you please help me convert this code so that it will run in VB.NET Thank You Mark Hollander Private Type USER_INFO Name As String
8
by: Greg Lyles | last post by:
Hi all, I'm trying to develop an ASP.NET 2.0 website and am running into some real problems with what I thought would be a relatively simple thing to do. In a nutshell, I'm stuck on trying to...
3
by: roberthornsby | last post by:
Hi, Please can you help me with this query which I am struggling with? Here is a simplified version of the table I am trying to work with VehicleId, PurchaseId, PurchaseDate, Comment 1, 1, ...
0
by: magicofureyes | last post by:
Hello Guys im a just a new user and i dnt knw much abt Xml i want to upload a new template in Blogger so got some free coding but when i save this code in Blogger template it say '''' Your...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.