Hi clc.
Following is my reply to a question posted in a newsgroup,
in which, a person said my advice was wrong without
saying where and why. I turn to clc.
[BEGINS] Hi friends, I cam across these questions and seem baffled by these Can anyone tell me answers to this?
This code may have bugs!. If any suggest remedy to this else give output!
#1.c #include<stdio.h>
You should include <stdlib.h> for malloc.
main() { void *pointer; void *vector; void *address; void *location;
The prototype of malloc is:
void *malloc ( size_t );
where,
size_t is an unsigned integer typedefe in <stdlib.h>.
pointer=malloc(-1);
Read: http://www.geocities.com/vijoeyz/faq/c/unsigned2.txt
to know about how a negative integer is assigned to an unsigned
int.
vector=malloc(0);
Each compiler is free to define the behaviour of malloc () when
the size is 0. Usually, the compiler documents how it does.
Two possibilies are:
When the requested size is zero
* return a NULL pointer.
* Assume some non-zero size
In either case, using the return value malloc() can cause undefined
behaviour.
address=malloc(1);
This is OK.
location=NULL;
free(pointer); free(vector); free(address);
If the corresponding mallocs were successful, then this is OK.
free(location);
This is also legal, but no action occurs for free ( NULL ).
[ENDS] 17 935
"Vijay Kumar R Zanvar" <vi***********@globaledgesoft.com> wrote: Following is my reply to a question posted in a newsgroup, in which, a person said my advice was wrong without saying where and why. I turn to clc.
vector=malloc(0); Each compiler is free to define the behaviour of malloc () when the size is 0. Usually, the compiler documents how it does. Two possibilies are:
When the requested size is zero * return a NULL pointer.
This is correct.
* Assume some non-zero size
This is not; or rather, it is misleading. malloc(0) is allowed to return
(in C89) just any unique pointer; in C99, it is allowed to behave as if
it were some non-zero size _except that the pointer must not be
dereferenced_. That restriction is not present when you _just_ assume
some non-zero size.
In either case, using the return value malloc() can cause undefined behaviour.
Well, no. Not quite. Using it _as if it pointed to some usable object_
causes undefined behaviour.
In C89, if you get a non-null result, I'm not sure whether, e.g.,
comparing it for equality with any other same-type or null pointer
invokes UB; I can't determine whether it is supposed to be a _valid_
unique pointer, and if it isn't, even the comparison is UB. If it is,
the comparison must work.
In C99, if you get a non-null result, that result must be a valid
pointer, and can be treated as any pointer _except_ that it cannot be
dereferenced. For example, you can compare it for equality, you can pass
it to a function (which may then not deref it, but...), you can assign
it to a pointer variable. This is also true if you get a null pointer,
under either Standard. address=malloc(1);
This is OK.
Albeit useless, of course, but I presume that was not the point of the
code. location=NULL;
free(pointer); free(vector); free(address);
If the corresponding mallocs were successful, then this is OK.
Even if not, this is OK. An unsuccessful malloc() returns a null
pointer, and free(0) is legal (and a no-op) under both Standards.
Richard
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message news:40****************@news.individual.net... "Vijay Kumar R Zanvar" <vi***********@globaledgesoft.com> wrote:
Following is my reply to a question posted in a newsgroup, in which, a person said my advice was wrong without saying where and why. I turn to clc.
vector=malloc(0);
Each compiler is free to define the behaviour of malloc () when the size is 0. Usually, the compiler documents how it does. Two possibilies are:
When the requested size is zero * return a NULL pointer.
This is correct.
* Assume some non-zero size
This is not; or rather, it is misleading. malloc(0) is allowed to return (in C89) just any unique pointer; in C99, it is allowed to behave as if it were some non-zero size _except that the pointer must not be dereferenced_. That restriction is not present when you _just_ assume some non-zero size.
In either case, using the return value malloc() can cause undefined behaviour.
Well, no. Not quite. Using it _as if it pointed to some usable object_ causes undefined behaviour. In C89, if you get a non-null result, I'm not sure whether, e.g., comparing it for equality with any other same-type or null pointer invokes UB; I can't determine whether it is supposed to be a _valid_ unique pointer, and if it isn't, even the comparison is UB. If it is, the comparison must work. In C99, if you get a non-null result, that result must be a valid pointer, and can be treated as any pointer _except_ that it cannot be dereferenced. For example, you can compare it for equality, you can pass it to a function (which may then not deref it, but...), you can assign it to a pointer variable. This is also true if you get a null pointer, under either Standard.
address=malloc(1);
This is OK.
Albeit useless, of course, but I presume that was not the point of the code.
location=NULL;
free(pointer); free(vector); free(address);
If the corresponding mallocs were successful, then this is OK.
Even if not, this is OK. An unsuccessful malloc() returns a null pointer, and free(0) is legal (and a no-op) under both Standards.
Richard
Thank you very much. This clears my doubt.
Vijay
Vijay Kumar R Zanvar <vi***********@globaledgesoft.com> spoke thus:
<non-authoratative> You should include <stdlib.h> for malloc.
Correct. main()
The return type of main (int) must be specified in C99, and it's a
good idea to explicitly enumerate its parameters (either void or int,
char**) anyway.
The prototype of malloc is: void *malloc ( size_t );
where, size_t is an unsigned integer typedefe in <stdlib.h>.
I believe this is correct.
When the requested size is zero * return a NULL pointer. * Assume some non-zero size
Part of 7.20.3 (I believe C89 and C99 say essentially the same thing
here) reads thus:
"If the size of the space requested is zero, the behavior is
implementation-defined: either a null pointer is returned, or the
behavior is as if the size were some nonzero value, except that the returned
pointer shall not be used to access an object."
location=NULL;
free(pointer); free(vector); free(address);
If the corresponding mallocs were successful, then this is OK.
They are OK regardless; if the mallocs failed these pointers are NULL,
and as you note free( NULL ); is entirely legal. This assumes, of
course, that the portion of 7.20.3 I quoted above does not apply here.
--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
On Mon, 5 Apr 2004 17:48:57 +0530, "Vijay Kumar R Zanvar"
<vi***********@globaledgesoft.com> wrote in comp.lang.c:
One more point I have not seen: Hi clc.
Following is my reply to a question posted in a newsgroup, in which, a person said my advice was wrong without saying where and why. I turn to clc.
[BEGINS]
Hi friends, I cam across these questions and seem baffled by these Can anyone tell me answers to this?
This code may have bugs!. If any suggest remedy to this else give output!
#1.c #include<stdio.h> You should include <stdlib.h> for malloc.
main() { void *pointer; void *vector; void *address; void *location;
The prototype of malloc is:
void *malloc ( size_t );
where, size_t is an unsigned integer typedefe in <stdlib.h>.
pointer=malloc(-1);
Read: http://www.geocities.com/vijoeyz/faq/c/unsigned2.txt to know about how a negative integer is assigned to an unsigned int.
vector=malloc(0);
Each compiler is free to define the behaviour of malloc () when the size is 0. Usually, the compiler documents how it does.
Both versions of the C standard state that the result of calling
malloc() with a parameter of 0 is implementation-defined, which is a
term with a very specific definition in the standard.
A compiler is "free" to select among the behaviors specifically
allowed by the standard, not any behavior. And it must document its
choice.
Two possibilies are:
In fact, the only two possibilities...
When the requested size is zero * return a NULL pointer. * Assume some non-zero size
Richard seems to think there is something vague about the "unique
pointer" phrase used by c89/90. I think the meaning is rather simple.
It merely means that a non-NULL pointer returned by malloc(0) must be
different every time you make that call in a program. It must also be
different from every pointer returned by a successful non-zero
allocation call, and the address of every non-dynamic object existing
in a program.
In other words, it must not compare equal to any other valid pointer
value in a program.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Jack Klein <ja*******@spamcop.net> wrote: On Mon, 5 Apr 2004 17:48:57 +0530, "Vijay Kumar R Zanvar" <vi***********@globaledgesoft.com> wrote in comp.lang.c:
When the requested size is zero * return a NULL pointer. * Assume some non-zero size Richard seems to think there is something vague about the "unique pointer" phrase used by c89/90. I think the meaning is rather simple. It merely means that a non-NULL pointer returned by malloc(0) must be different every time you make that call in a program. It must also be different from every pointer returned by a successful non-zero allocation call, and the address of every non-dynamic object existing in a program.
Yes; I do not think _this_ part is vague at all.
In other words, it must not compare equal to any other valid pointer value in a program.
This, however, I'm not sure about. If the general consensus is that "a
unique pointer" means "a _valid_ unique pointer", fine by me. However,
if you want to be nasty, "a unique pointer" can also be read as "a
unique, possibly not even valid, pointer". I agree that this would be
against the spirit of the Standard; I'm less certain that it goes
against the letter.
Richard
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:40****************@news.individual.net... Jack Klein <ja*******@spamcop.net> wrote: Richard seems to think there is something vague about the "unique pointer" phrase used by c89/90.
[snip] In other words, it must not compare equal to any other valid pointer value in a program.
This, however, I'm not sure about. If the general consensus is that "a unique pointer" means "a _valid_ unique pointer", fine by me. However, if you want to be nasty, "a unique pointer" can also be read as "a unique, possibly not even valid, pointer". I agree that this would be against the spirit of the Standard; I'm less certain that it goes against the letter.
How would you define "valid" in this context? Seems to me that it doesn't
matter; it would be UB to dereference the pointer, so what difference does
it make?
"Alex" <me@privacy.net> wrote: "Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message news:40****************@news.individual.net... This, however, I'm not sure about. If the general consensus is that "a unique pointer" means "a _valid_ unique pointer", fine by me. However, if you want to be nasty, "a unique pointer" can also be read as "a unique, possibly not even valid, pointer". I agree that this would be against the spirit of the Standard; I'm less certain that it goes against the letter.
How would you define "valid" in this context? Seems to me that it doesn't matter; it would be UB to dereference the pointer, so what difference does it make?
An invalid pointer value could cause a segfault even when it's being
compared for equality to another pointer. This is not allowed for a
valid pointer, no matter whether that pointer points at a trap value or
otherwise illegal object or not.
For example,
int i;
int *valid_p=&i;
int *invalid_p;
int *null_p=NULL;
if (valid_p==null_p) /* This is a legal comparison, even though you
; cannot dereference null_p. */
if (valid_p==invalid_p) /* This is an illegal comparison; invalid_p
; has not been initialised, and the pointer
itself may be a trap value -> UB. */
Richard
"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:c4**********@chessie.cirr.com... Vijay Kumar R Zanvar <vi***********@globaledgesoft.com> spoke thus: When the requested size is zero * return a NULL pointer. * Assume some non-zero size Part of 7.20.3 (I believe C89 and C99 say essentially the same thing here) reads thus:
"If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the
returned pointer shall not be used to access an object."
location=NULL;
free(pointer); free(vector); free(address);
If the corresponding mallocs were successful, then this is OK.
They are OK regardless; if the mallocs failed these pointers are NULL, and as you note free( NULL ); is entirely legal. This assumes, of course, that the portion of 7.20.3 I quoted above does not apply here.
Why would 7.20.3 matter? Either the pointers are NULL, in which case free()
is a no-op, or the pointer is some value which could have resulted from a
non-zero-sized malloc, in which case the value should be a legal argument to
free().
I'm assuming though that "shall not be used to access an object" is
equivalent to "shall not be dereferenced", which free() wouldn't be doing.
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:40****************@news.individual.net... Jack Klein <ja*******@spamcop.net> wrote: In other words, it must not compare equal to any other valid pointer value in a program.
This, however, I'm not sure about. If the general consensus is that "a unique pointer" means "a _valid_ unique pointer", fine by me. However, if you want to be nasty, "a unique pointer" can also be read as "a unique, possibly not even valid, pointer". I agree that this would be against the spirit of the Standard; I'm less certain that it goes against the letter.
I don't see how one can read 7.20.3 as allowing malloc(0) to return an
invalid pointer, even if unique. If the implementation chooses for
malloc(0) to behave "as if the size were some nonzero value", then the
returned pointer MUST be valid or NULL because those are the only possible
returns if malloc() were called with a nonzero size.
It also seems easier for an implementation to return unique pointers if
they're valid, since it can just fall through to the code for allocating a
minimum-sized object.
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:40****************@news.individual.net... "Alex" <me@privacy.net> wrote: How would you define "valid" in this context? Seems to me that it
doesn't matter; it would be UB to dereference the pointer, so what difference
does it make?
An invalid pointer value could cause a segfault even when it's being compared for equality to another pointer. This is not allowed for a valid pointer, no matter whether that pointer points at a trap value or otherwise illegal object or not.
Where does it say that operations on an invalid pointer (other than
dereferencing) invoke undefined behavior? And on what systems is that
likely/possible such that the standard allows for it?
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
"Stephen Sprunk" <st*****@sprunk.org> a écrit dans le message de
news:31******************************@news.teranew s.com...
Hi, "Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message news:40****************@news.individual.net... "Alex" <me@privacy.net> wrote: How would you define "valid" in this context? Seems to me that it doesn't matter; it would be UB to dereference the pointer, so what difference does it make? An invalid pointer value could cause a segfault even when it's being compared for equality to another pointer. This is not allowed for a valid pointer, no matter whether that pointer points at a trap value or otherwise illegal object or not.
Where does it say that operations on an invalid pointer (other than dereferencing) invoke undefined behavior?
It's said in the standard. It's in the sixth point of 6.5.9 concerning
equality operators, in fact a footnote of the paragraph:
"Two pointers compare equal if and only if both are null pointers, both are
pointers to the same object (including a pointer to an object and a
subobject at its beginning) or function, both are pointers to one past the
last element of the same array object, or one is a pointer to one past the
end of one array object and the other is a pointer to the start of a
different array object that happens to immediately follow the first array
object in the address space [91]"
91 : "Two objects may be adjacent in memory because they are adjacent
elements of a larger array or adjacent members of a structure with no
padding between them, or because the implementation chose to place them so,
even though they are unrelated. If prior invalid pointer operations (such
accesses outside array bounds) produced undefined behavior, subsequent
comparisons also produce undefined behavior."
Regards.
Regis S
-- Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
"Rgis Troadec" <re**@wanadoo.fr> wrote in message
news:c5**********@news-reader4.wanadoo.fr... "Stephen Sprunk" <st*****@sprunk.org> a crit dans le message de news:31******************************@news.teranew s.com... "Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message news:40****************@news.individual.net... An invalid pointer value could cause a segfault even when it's being compared for equality to another pointer. This is not allowed for a valid pointer, no matter whether that pointer points at a trap value
or otherwise illegal object or not. Where does it say that operations on an invalid pointer (other than dereferencing) invoke undefined behavior?
It's said in the standard. It's in the sixth point of 6.5.9 concerning equality operators, in fact a footnote of the paragraph:
"Two pointers compare equal if and only if both are null pointers, both
are pointers to the same object (including a pointer to an object and a subobject at its beginning) or function, both are pointers to one past the last element of the same array object, or one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space [91]"
91 : "Two objects may be adjacent in memory because they are adjacent elements of a larger array or adjacent members of a structure with no padding between them, or because the implementation chose to place them
so, even though they are unrelated. If prior invalid pointer operations (such accesses outside array bounds) produced undefined behavior, subsequent comparisons also produce undefined behavior."
I don't see anything in there that says the following code produces
undefined behavior:
void *a, *b;
a = malloc(1);
free(a);
b = a;
Of course, a and b are both useless at the end, but why would assigning an
invalid pointer be undefined?
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
In article <news:46******************************@news.terane ws.com>
Stephen Sprunk <st*****@sprunk.org> writes: I don't see anything in there that says the following code produces undefined behavior:
void *a, *b; a = malloc(1); free(a); b = a;
In my C99 draft, it is in section 7.14.3:
... The value of a pointer that refers to freed space is indeterminate.
combined with 3.18:
3.18 Undefined behavior
[#1] Behavior, upon use of [various cases deleted], or of
indeterminately valued objects, for which this International
Standard imposes no requirements. ...
Of course, a and b are both useless at the end, but why would assigning an invalid pointer be undefined?
Why are there separate "." and "->" operators, when the type of
the left-hand side would disambiguate? Why are there += and &=
operators, but no &&= operator?
The answer to this kind of question -- "why is it designed the way
it is" -- ultimately boils down to "because Dennis and/or the
ANSI/ISO C committee folks decided". If they were to say that such
pointers did *not* have undefined behavior, implementors would have
to do whatever is required to achieve that. If they said that
integer overflow had to trap at runtime, implementors would have
to do that. If they said that the result of the rand() function
was always 42, implementors would have to do that, too.
The art of language design (and standards-writing) lies in defining
enough to be useful, without defining so much as to cause more
problems than you solve. As you yourself note, "a and b are both
useless at the end" -- so what problems would additional defining
solve? The cost of such defining might be small, but what benefit
would it buy?
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
"Stephen Sprunk" <st*****@sprunk.org> writes:
[...] I don't see anything in there that says the following code produces undefined behavior:
void *a, *b; a = malloc(1); free(a); b = a;
Of course, a and b are both useless at the end, but why would assigning an invalid pointer be undefined?
Quick answer: because the standard says so (chapter and verse have
been cited elsewhere in this thread).
Longer answer: for much the same reason that the following produces
undefined behavior:
void *a, *b;
b = a;
An uninitialized variable has an indeterminate value; referring to
that value invokes undefined behavior. A pointer whose value has been
passed to free() also has an indeterminate value.
Referring to such a value almost certainly indicates a programming
error; there's nothing useful you can do with the value anyway. Part
of the rationale for making such references undefined behavior, I
think, is to allow for implementations that might be able to detect
and diagnose such errors. Since such detection is impractical for
most implementations, it wasn't practical to require it. Calling it
undefined behavior was the only real way to allow detection without
imposing an undue burden on implementors.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
"Stephen Sprunk" <st*****@sprunk.org> wrote: I don't see anything in there that says the following code produces undefined behavior:
void *a, *b; a = malloc(1); free(a); b = a;
Of course, a and b are both useless at the end, but why would assigning an invalid pointer be undefined?
These days, systems have hardware-based memory protection. In PCs this
takes the form that a hardware exception occurs if you try and write
outside your process's address space. But there are also other systems
where the mere act of loading a register designed for memory access
with a value outside the process's address space, causes a hardware
exception. After the free() call, 'a' might now be pointing to a
different process's address space, hence the possibility for UB
when it is loaded to registers for the copy to b.
"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84*************************@posting.google.co m... "Stephen Sprunk" <st*****@sprunk.org> wrote: I don't see anything in there that says the following code produces undefined behavior:
void *a, *b; a = malloc(1); free(a); b = a;
Of course, a and b are both useless at the end, but why would assigning
an invalid pointer be undefined?
These days, systems have hardware-based memory protection. In PCs this takes the form that a hardware exception occurs if you try and write outside your process's address space. But there are also other systems where the mere act of loading a register designed for memory access with a value outside the process's address space, causes a hardware exception. After the free() call, 'a' might now be pointing to a different process's address space, hence the possibility for UB when it is loaded to registers for the copy to b.
Ah, I wasn't aware that such systems existed. That explains it.
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
> where the mere act of loading a register designed for memory access with a value outside the process's address space, causes a hardware exception. After the free() call, 'a' might now be pointing to a different process's address space, hence the possibility for UB when it is loaded to registers for the copy to b.
Oh? I have yet to see this on any existing system. But why not. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Volodymyr Sadovyy |
last post by:
Hi.
Can somebody refer me to resource with specified/analyzed/approximated
productivity in Java coding and Java code review tasks? Coding
productivity is more described in the net, but I didn't...
|
by: Leo |
last post by:
I have the following problem:
When looking at a document, we would like to see what the review state
of that document is.
I set out to make a custom document_view page template based on the...
|
by: poisondart |
last post by:
Hi,
I'm not sure if this is the right group to post this. If not, then I
would appreciate if somebody could point me to the correct group.
This is my first time releasing software to the...
|
by: Ben Hanson |
last post by:
I have created an open source Notepad program for Windows in C++ that allows
search and replace using regular expressions (and a few other extras). It
is located at...
|
by: Mark A. Nicolosi |
last post by:
I've been trying to learn C for quite a while. But I've had trouble
with the
lack of good quality online text (some of it's alright). But I finally
bought
a book on C, Practical C. I like it...
|
by: Vijay Kumar R Zanvar |
last post by:
Hi,
Is the following strncpy implementation
according to C99?
char *
strncpy ( char *s, const char *t, size_t n )
{
char *p = s;
size_t i = 0;
|
by: Vijay Kumar R Zanvar |
last post by:
Hi c.l.c.
I think it's time that I bring it up. Over the last 2-3 months,
I have been trying to build my C FAQ page which has around
40 C questions. Few of them have been adopted from c.l.c. ...
|
by: Johan Tibell |
last post by:
I would be grateful if someone had a minute or two to review my hash
table implementation. It's not yet commented but hopefully it's short
and idiomatic enough to be readable. Some of the code...
|
by: tatata9999 |
last post by:
Thanks.
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
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...
|
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...
|
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...
|
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)...
|
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: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 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 former...
| |