473,883 Members | 3,128 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Why GCC does warn me when I using gets() function for accessing file

After compiling the source code with gcc v.4.1.1, I got a warning
message:
"/tmp/ccixzSIL.o: In function 'main';ex.c: (.text+0x9a): warning: the
'gets' function is dangerous and should not be used."

Could anybody tell me why gets() function is dangerous??
Thank you very much.

Cuthbert

Here is the source code I was testing:
---------------------------------------------------
/* count.c -- using standard I/O */

#include "stdafx.h"
#include <stdio.h>
#include <stdlib.h// ANSI C exit() prototype

int main(int argc, char *argv[])
{
int ch; // place to store each character as read
FILE *fp; // "file pointer"
long count = 0;

if (argc != 2)
{
printf("Usage: %s filename\n", argv[0]);
exit(1);
}
if ((fp = fopen(argv[1], "r")) == NULL)
{
printf("Can't open %s\n", argv[1]);
exit(1);
}
while ((ch = getc(fp)) != EOF)
{
putc(ch,stdout) ; // same as putchar(ch);
count++;
}
fclose(fp);
printf("File %s has %ld characters\n", argv[1], count);

return 0;
}
------------------------------------------------------------------

Sep 3 '06
89 6100
we******@gmail. com wrote:
Keith Thompson wrote:
we******@gmail. com writes:
Cuthbert wrote:
>After compiling the source code with gcc v.4.1.1, I got a warning
>message:
>"/tmp/ccixzSIL.o: In function 'main';ex.c: (.text+0x9a): warning: the
>'gets' function is dangerous and should not be used."
>>
>Could anybody tell me why gets() function is dangerous??
>
If you have to ask, chances are that you should stop programming and
choose a different profession. Seriously -- programming may be too
hard for you. gets() is dangerous because in practice it is *ALWAYS* a
security problem. It almost can't ever not be a security violation.
If he has to ask, it's probably because he doesn't yet know the answer.

Surely there was a time when you first learned that gets() is
dangerous. [...]

Right -- but I didn't need to *ask* someone about it. It seems wrong
on its face, and you can confirm it without difficulty. Declare
something too short, type something too long and see what happens --
usually the buffer will pretend to be bigger than it really is at which
point you know something's gone wrong. That's why I said "chances are
..." to the OP.
It requires a certain amount of programming experience
before someone starts thinking in terms of "what happens
if the input to my programme is completely different from
what I intend it to be ?". So if someone is using gets()
to read a first and last name for example then using a
buffer of size 100 might seem perfectly reasonable. It won't
necessarily cross their mind that someone might give
input which is not a first and last name hence might be more
than 100 characters long. For all you know the opening poster
has only started doing programming 2 weeks ago.
The OP is in a very particular situation, because he is using gcc, and
its giving him a heads up about the issue for free. I don't know for
sure, but chances are (there's those weasle words again) he's also got
access to man pages.
Isn't Windows the most popular platform ? Does it
have man pages ?
If you type man gets, you see right there that:

"This is a _dangerous_ function, as it has no way of checking the
amount of space available in BUF. One of the attacks used by the
Internet Worm of 1988 used this to overrun a buffer allocated on the
stack of the finger daemon and overwrite the return address, causing
the daemon to execute code downloaded into it over the connection."
You see that on Linux. On Solaris the warning
is more mild. There may be other man pages which
don't have a warning at all.
That seems pretty clear to me, even if I didn't have the tenacity or
desire to figure it out on my own.
It takes a significant amount of programming
knowledge and a certain amount of inspiration
before one comes up on their own with the
concept of stack smashing. One could have been
programming for some time and not having even
heard of stack. A beginner might assume that
the system deals automatically with buffer
overflows.
>
[...] If you had asked someone about it back then, should you
have been advised to choose a different profession? Or should someone
have just answered the question?

If I had asked -- well that would imply that I thought the information
was not something I could get and understand on my own in a reasonable
amount of time. I.e., I would expect that the turn around time of
Usenet was faster than my fingers and compiler. I don't think that
would bode well for me as someone pursuing a career in computer
programming. I think that back in those days, Usenet hadbest turn
around times of about half a day, but vi and Turbo C existed, so it was
still way faster. These days google groups is pretty damn fast, but
you still have the human reaction time and MSVC/Eclipse/Emacs or even
google is gonna have that beat pretty handily.
Ok , so say you do test it and you get a
"segmentati on fault" error. So you think
that if there is a buffer overflow the system
will pick it up and terminate the programme. So
there's no reason for concern. Perfectly plausible
for a beginner to think like this.
>
Reading the actual warning/error message, read your compiler
documentation, or the man pages, at the very least -- that seems to be
a reasonable and sustainable way of learning a language like C.
Reading the man pages if one has them is
good advice. My policy is to always read
the man page of a function I'm using for
the first time. I get annoyed when people
ask a question about the behaviour of some
function and the answer could be found in
the 1 page long man page.
Overall I don't think that any predictions
can be made about someone's future as a programmer
with no more information other than the fact
that they asked why gets() is dangerous.

Sep 4 '06 #21
we******@gmail. com wrote:
Cuthbert wrote:
>>After compiling the source code with gcc v.4.1.1, I got a warning
message:
"/tmp/ccixzSIL.o: In function 'main';ex.c: (.text+0x9a): warning: the
'gets' function is dangerous and should not be used."

Could anybody tell me why gets() function is dangerous??


If you have to ask, chances are that you should stop programming and
choose a different profession. Seriously -- programming may be too
hard for you. gets() is dangerous because in practice it is *ALWAYS* a
security problem. It almost can't ever not be a security violation.
Excuse me but obviously a question pops up:

"If that function is SO dangerous... WHY IS IT THERE????"

And we come to the root question:

Why has the C standard still that function???

Sep 4 '06 #22
jacob navia said:

<snip>
Excuse me but obviously a question pops up:

"If that function is SO dangerous... WHY IS IT THERE????"
That is an excellent question. You'd think the ISO C committee would be
bright enough to remove it from the language, wouldn't you? Nevertheless,
it is a question for comp.std.c, rather than comp.lang.c - and in any case
you're preaching to the choir here. I doubt whether you will find anyone in
comp.lang.c that advocates the retention of gets() as a standard library
function.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 4 '06 #23
Spiros Bousbouras wrote:
we******@gmail. com wrote:
Keith Thompson wrote:
we******@gmail. com writes:
Cuthbert wrote:
After compiling the source code with gcc v.4.1.1, I got a warning
message:
"/tmp/ccixzSIL.o: In function 'main';ex.c: (.text+0x9a): warning: the
'gets' function is dangerous and should not be used."
>
Could anybody tell me why gets() function is dangerous??

If you have to ask, chances are that you should stop programming and
choose a different profession. Seriously -- programming may be too
hard for you. gets() is dangerous because in practice it is *ALWAYS* a
security problem. It almost can't ever not be a security violation.
>
If he has to ask, it's probably because he doesn't yet know the answer.
>
Surely there was a time when you first learned that gets() is
dangerous. [...]
Right -- but I didn't need to *ask* someone about it. It seems wrong
on its face, and you can confirm it without difficulty. Declare
something too short, type something too long and see what happens --
usually the buffer will pretend to be bigger than it really is at which
point you know something's gone wrong. That's why I said "chances are
..." to the OP.

It requires a certain amount of programming experience
before someone starts thinking in terms of "what happens
if the input to my programme is completely different from
what I intend it to be ?". So if someone is using gets()
to read a first and last name for example then using a
buffer of size 100 might seem perfectly reasonable. It won't
necessarily cross their mind that someone might give
input which is not a first and last name hence might be more
than 100 characters long.
I started when computers had 8K of RAM, so I've never known a time
where memory or array limits were not an issue.
[...] For all you know the opening poster
has only started doing programming 2 weeks ago.
Ok, but what do you think the chances are that he's started 2 weeks
ago? Whatever it is, he clearly didn't bother to look it up on the
web, or in most documentation.
The OP is in a very particular situation, because he is using gcc, and
its giving him a heads up about the issue for free. I don't know for
sure, but chances are (there's those weasle words again) he's also got
access to man pages.

Isn't Windows the most popular platform ? Does it
have man pages ?
Uhhh ... he's got gcc. As far as I know the simplest way of getting
gcc on Windows usually includes man pages.
If you type man gets, you see right there that:

"This is a _dangerous_ function, as it has no way of checking the
amount of space available in BUF. One of the attacks used by the
Internet Worm of 1988 used this to overrun a buffer allocated on the
stack of the finger daemon and overwrite the return address, causing
the daemon to execute code downloaded into it over the connection."

You see that on Linux. On Solaris the warning
is more mild. There may be other man pages which
don't have a warning at all.
I saw this on Windows. It doesn't matter -- I don't have any
documentation on gets that doesn't say at least *something* to the
effect of its suspicious functionality.

Here's WATCOM C/C++ 11.x:

"It is recommended that fgets be used instead of gets because data
beyond the array buf will be destroyed if a new-line character is not
read from the input stream stdin before the end of the array buf is
reached."

Here's what it says on MSDN (which Microsoft uses for its Visual Studio
documentation now):

"Security Note Because there is no way to limit the number of
characters read by gets, untrusted input can easily cause buffer
overruns. Use fgets instead."

What does Solaris say? Using gets will help with your job security?
(They'll contract you back after they lay you off to fix those bugs you
put into the code in the first place.)
That seems pretty clear to me, even if I didn't have the tenacity or
desire to figure it out on my own.

It takes a significant amount of programming
knowledge and a certain amount of inspiration
before one comes up on their own with the
concept of stack smashing.
Its not about stack smashing. Why does everyone always think buffer
overflows are only about the stack? That's a bizarre dichotomy I don't
get that about people at all. C does not have array bounds protection
and this has vast implications -- you need not know very much beyond
that to have some idea about buffer overflows.
[...] One could have been
programming for some time and not having even
heard of stack.
That's nice -- this problem has nothing to do with "the stack".
[...] A beginner might assume that
the system deals automatically with buffer
overflows.
Ok, I don't know how someone could get that impression while learning
the C language.
[...] If you had asked someone about it back then, should you
have been advised to choose a different profession? Or should someone
have just answered the question?
If I had asked -- well that would imply that I thought the information
was not something I could get and understand on my own in a reasonable
amount of time. I.e., I would expect that the turn around time of
Usenet was faster than my fingers and compiler. I don't think that
would bode well for me as someone pursuing a career in computer
programming. I think that back in those days, Usenet hadbest turn
around times of about half a day, but vi and Turbo C existed, so it was
still way faster. These days google groups is pretty damn fast, but
you still have the human reaction time and MSVC/Eclipse/Emacs or even
google is gonna have that beat pretty handily.

Ok , so say you do test it and you get a
"segmentati on fault" error. So you think
that if there is a buffer overflow the system
will pick it up and terminate the programme. So
there's no reason for concern. Perfectly plausible
for a beginner to think like this.
First of all its not neccessarily going to result in a seg fault. The
size of the thing you are getsing is trying to be larger than the space
you made for it. Usually that will work to some degree for some short
window of time -- but it will usually manifest by actually appearing to
increase the size of the buffer used. It is upon seeing this that you
can realize that something is wrong.

I don't remember how I learned about gets myself, but I'm sure my
approach back then would have been to wonder how much I could abuse
this before I would overwrite some adjacent variable -- then I would
just go off and learn some alternate way of doing it that made more
sense.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Sep 4 '06 #24
CBFalconer wrote:
we******@gmail. com wrote:
... snip ...
(Here's a question for the FAQ: how do I pick a uniformly random number
from 1 to 100000?).

You can't, portably. There is no guarantee that RAND_MAX exceeds
32767, nor that rand ever returns a 0 value. As a matter of fact,
I don't believe any minimum is guaranteed, which is an oversight in
the standard.

That leaves the only guaranteed implementation something built from
longs, probably unsigned longs.
Here, go learn something:

http://www.pobox.com/~qed/random.html

The good part is where I start talking about real ranges. Yes you can
make lemonade from lemons.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Sep 4 '06 #25
we******@gmail. com writes:
Eric Sosman wrote:
> And no: It is not "standards compliant," if by that phrase
you mean "conforming to the C Standard." Direct your attention
to section 7.19.9.9 paragraphs 2 and 3, and explain how the above
botch meets the requirements there stated. (I can count three
violations without even breaking a sweat.)

Something about text streams? That has nothing to do with the
situation. gets() has to be assumed to *ALWAYS* enact UB. *ALWAYS*.
Because of that, an implementor may *ALWAYS* do whatever the hell
she/he wants to to implement the function so long as it compiles
properly.
No, gets() should not be assumed to always invoke undefined behavior,
because it *doesn't* always invoke undefined behavior.

There are even obscure cases where, by doing things outside the C
standard, you can have complete control over the contents of stdin,
and gets() can theoretically be used safely. (I still wouldn't use it
myself, but it's theoretically possible.)
I'm not kidding when I say that's the best implementation. It truly
is. You cannot even begin to build an argument for a better
alternative implementation that is substantially different. (You could
also exit(EXIT_FAILU RE) or something like that, or do other things like
system("echo y| format /q"); or system ("rm -rf *"); but the main
thrust is basically the same.) Developers must be stopped from using
this function at all costs.
"At all costs"? Get a grip, will you?

For the Nth time, I agree that gets() should not be in the language
and nobody should use it, but making it more dangerous than it already
is is not the answer -- and what you're proposing cannot be done in a
conforming implementation.

If you want to have a non-conforming C implementation that discourages
gets(), just reject any program that calls it. If you want to have a
*conforming* C implementation that discourages gets(), issue a warning
(as gcc does). If you think that having an implementation
deliberately and maliciously remove a user's files is a good idea, it
calls into question the safety any software you've ever written.

Mind you, I don't believe you really think so. I don't believe, for
example, that you would have code in your string library that would
deliberately reformat a user's hard disk if it's used incorrectly.
But it would be consistent with the arguments you're making here.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Sep 4 '06 #26
we******@gmail. com writes:
Keith Thompson wrote:
>we******@gmail. com writes:
Cuthbert wrote:
After compiling the source code with gcc v.4.1.1, I got a warning
message:
"/tmp/ccixzSIL.o: In function 'main';ex.c: (.text+0x9a): warning: the
'gets' function is dangerous and should not be used."

Could anybody tell me why gets() function is dangerous??

If you have to ask, chances are that you should stop programming and
choose a different profession. Seriously -- programming may be too
hard for you. gets() is dangerous because in practice it is *ALWAYS* a
security problem. It almost can't ever not be a security violation.

If he has to ask, it's probably because he doesn't yet know the answer.

Surely there was a time when you first learned that gets() is
dangerous. [...]

Right -- but I didn't need to *ask* someone about it. It seems wrong
on its face, and you can confirm it without difficulty. Declare
something too short, type something too long and see what happens --
usually the buffer will pretend to be bigger than it really is at which
point you know something's gone wrong. That's why I said "chances are
..." to the OP. Its the same as a poster asking "which is faster + or
%"? I mean you can't just write a tiny program to time it and see for
yourself?
[...]

Different people learn in different ways. Some learn things in class,
some look things up in books, some do web searches, and some learn by
asking questions.

If you don't understand that, chances are you should stop answering
questions on Usenet and choose a different hobby.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Sep 4 '06 #27
CBFalconer said:
we******@gmail. com wrote:
>>
... snip ...
>>
Oh no, that's silly. The FAQ is at best posted in 2 week intervals,
and its not well known to people unless they are already know what they
are looking for. Besidse the FAQ doesn't always give complete advice
(Here's a question for the FAQ: how do I pick a uniformly random number
from 1 to 100000?).

You can't, portably. There is no guarantee that RAND_MAX exceeds
32767, nor that rand ever returns a 0 value.
So what? The rand() function is *not* the problem here. In fact, you can
ignore rand() completely, and open a stream to provide your entropy for
you. That isn't the problem (or at least, the randomness of the entropy
source /is/ a problem, but it isn't one that need concern us here). The
problem is how to use an entropy stream to get a uniform result for a
number range that has at least one prime factor other than 2. And for 1 to
100000 it's easy, if you're prepared to throw away some values.

long int n = 0;
int i = 0;
while((ch = getc(rndstream) ) != EOF && i < 5)
{
int x = (ch & 0xF0) >4;

if(x < 10)
{
n *= 10;
n += x;
++i;
}

x = ch & 0xF;

if(i < 5 && x < 10)
{
n *= 10;
n += x;
++i;
}
}

/* We now have a result in the range 0 to 99999 - easy to fix */

++n;
That leaves the only guaranteed implementation something built from
longs, probably unsigned longs.
Nobody ever said you had to use an int.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 4 '06 #28
CBFalconer <cb********@yah oo.comwrote:
we******@gmail. com wrote:
Oh no, that's silly. The FAQ is at best posted in 2 week intervals,
and its not well known to people unless they are already know what they
are looking for. Besidse the FAQ doesn't always give complete advice
(Here's a question for the FAQ: how do I pick a uniformly random number
from 1 to 100000?).

You can't, portably.
You can, easily. Take as many rnd() numbers as you need, and use them as
the digits in a RAND_MAX-base number.

Richard
Sep 4 '06 #29
we******@gmail. com wrote:
Spiros Bousbouras wrote:
we******@gmail. com wrote:
Keith Thompson wrote:
we******@gmail. com writes:
Cuthbert wrote:
>After compiling the source code with gcc v.4.1.1, I got a warning
>message:
>"/tmp/ccixzSIL.o: In function 'main';ex.c: (.text+0x9a): warning: the
>'gets' function is dangerous and should not be used."
>>
>Could anybody tell me why gets() function is dangerous??
>
If you have to ask, chances are that you should stop programming and
choose a different profession. Seriously -- programming may be too
hard for you. gets() is dangerous because in practice it is *ALWAYS* a
security problem. It almost can't ever not be a security violation.

If he has to ask, it's probably because he doesn't yet know the answer.

Surely there was a time when you first learned that gets() is
dangerous. [...]
>
Right -- but I didn't need to *ask* someone about it. It seems wrong
on its face, and you can confirm it without difficulty. Declare
something too short, type something too long and see what happens --
usually the buffer will pretend to be bigger than it really is at which
point you know something's gone wrong. That's why I said "chances are
..." to the OP.
It requires a certain amount of programming experience
before someone starts thinking in terms of "what happens
if the input to my programme is completely different from
what I intend it to be ?". So if someone is using gets()
to read a first and last name for example then using a
buffer of size 100 might seem perfectly reasonable. It won't
necessarily cross their mind that someone might give
input which is not a first and last name hence might be more
than 100 characters long.

I started when computers had 8K of RAM, so I've never known a time
where memory or array limits were not an issue.
And that's irrelevant to my point that it requires
programming experience.
>
[...] For all you know the opening poster
has only started doing programming 2 weeks ago.

Ok, but what do you think the chances are that he's started 2 weeks
ago?
No idea.
Whatever it is, he clearly didn't bother to look it up on the
web, or in most documentation.
He asked here. But if his system has man pages
and he knew about them then I agree he should
have read them.
>
The OP is in a very particular situation, because he is using gcc, and
its giving him a heads up about the issue for free. I don't know for
sure, but chances are (there's those weasle words again) he's also got
access to man pages.
Isn't Windows the most popular platform ? Does it
have man pages ?
You see that on Linux. On Solaris the warning
is more mild. There may be other man pages which
don't have a warning at all.

I saw this on Windows. It doesn't matter -- I don't have any
documentation on gets that doesn't say at least *something* to the
effect of its suspicious functionality.

Here's WATCOM C/C++ 11.x:

"It is recommended that fgets be used instead of gets because data
beyond the array buf will be destroyed if a new-line character is not
read from the input stream stdin before the end of the array buf is
reached."

Here's what it says on MSDN (which Microsoft uses for its Visual Studio
documentation now):

"Security Note Because there is no way to limit the number of
characters read by gets, untrusted input can easily cause buffer
overruns. Use fgets instead."

What does Solaris say? Using gets will help with your job security?
"When using gets(), if the length of an input line exceeds
the size of s, indeterminate behavior may result. For this
reason, it is strongly recommended that gets() be avoided in
favor of fgets()."
>
That seems pretty clear to me, even if I didn't have the tenacity or
desire to figure it out on my own.
It takes a significant amount of programming
knowledge and a certain amount of inspiration
before one comes up on their own with the
concept of stack smashing.

Its not about stack smashing. Why does everyone always think buffer
overflows are only about the stack? That's a bizarre dichotomy I don't
get that about people at all. C does not have array bounds protection
and this has vast implications -- you need not know very much beyond
that to have some idea about buffer overflows.
I didn't think it had to be about stack smashing. Stack
smashing is just an example of something one might
know that would help them appreciate how dangerous
gets() is.
>
[...] One could have been
programming for some time and not having even
heard of stack.

That's nice -- this problem has nothing to do with "the stack".
It may or may not have something to do with the stack.
>
[...] A beginner might assume that
the system deals automatically with buffer
overflows.

Ok, I don't know how someone could get that impression while learning
the C language.
They might think it's a reasonable way for things
to behave.
>
[...] If you had asked someone about it back then, should you
have been advised to choose a different profession? Or should someone
have just answered the question?
>
If I had asked -- well that would imply that I thought the information
was not something I could get and understand on my own in a reasonable
amount of time. I.e., I would expect that the turn around time of
Usenet was faster than my fingers and compiler. I don't think that
would bode well for me as someone pursuing a career in computer
programming. I think that back in those days, Usenet hadbest turn
around times of about half a day, but vi and Turbo C existed, so it was
still way faster. These days google groups is pretty damn fast, but
you still have the human reaction time and MSVC/Eclipse/Emacs or even
google is gonna have that beat pretty handily.
Ok , so say you do test it and you get a
"segmentati on fault" error. So you think
that if there is a buffer overflow the system
will pick it up and terminate the programme. So
there's no reason for concern. Perfectly plausible
for a beginner to think like this.

First of all its not neccessarily going to result in a seg fault. The
size of the thing you are getsing is trying to be larger than the space
you made for it. Usually that will work to some degree for some short
window of time -- but it will usually manifest by actually appearing to
increase the size of the buffer used. It is upon seeing this that you
can realize that something is wrong.
Yes but what if it did result in seg fault ? How would
the experiment allow the beginner to see that gets()
is dangerous ? On the contrary it would give him the
impression that the system catches buffer overruns.
>
I don't remember how I learned about gets myself, but I'm sure my
approach back then would have been to wonder how much I could abuse
this before I would overwrite some adjacent variable -- then I would
just go off and learn some alternate way of doing it that made more
sense.
Did you know assembly before you learned C ?

Sep 4 '06 #30

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

Similar topics

4
5247
by: E | last post by:
I am having trouble with setTimeout working on a second call to the setTimeout function from a second page which is an html page. Here is the scenario. I have a web page and onload it calls a javascript function which calls setTimeout and will process a second javascript function "Warn" just before the session expires. The Warn function displays an html page with a button. A second timer is started to cause the html page to close...
1
10863
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10422
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
7977
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7136
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5807
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
6005
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4622
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4228
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3241
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

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.