Searched hist:33250 (Results 1 - 4 of 4) sorted by relevance
| /freebsd-9.3-release/usr.sbin/ypserv/ | ||
| H A D | Makefile | diff 33250 Wed Feb 11 17:15:32 MST 1998 wpaul Fix a bug in the database handle caching. This has to do with the way the underlying database code works. When dealing with first/next queries, you have the notion of a database 'cursor,' which is essentially a file pointer for the database. To select the first entry, you do a fetch with the R_FIRST flag set, then you can use the R_NEXT flag to enumerate the other entries in the database. Unfortunately, doing a direct fetch with no flag does _not_ set the 'cursor,' so you can't do a direct fetch and then enumerate the table from there. The bug is that cached handles generated as the result of a YPPROC_MATCH were being treated as though they were the same as handles generated by a YPPROC_FIRST, which is not the case. The manifestation is that if you do a 'ypmatch first-key-in-map map' followed by a yp_first()/yp_next() pair, the yp_first() and yp_next() both return the first key in the table, which makes the entry appear to be duplicated. A couple smaller things since I'm here: - yp_main.c and yp_error.c both have a global 'int debug' in them. For some reason, our cc/ld doesn't flag this as a multiply defined symbol even though it should. Removed the declaration from yp_main.c; we want the one in yp_error.c. - The Makefile wasn't installing ypinit in the right place. |
| H A D | yp_dblookup.c | diff 33250 Wed Feb 11 17:15:32 MST 1998 wpaul Fix a bug in the database handle caching. This has to do with the way the underlying database code works. When dealing with first/next queries, you have the notion of a database 'cursor,' which is essentially a file pointer for the database. To select the first entry, you do a fetch with the R_FIRST flag set, then you can use the R_NEXT flag to enumerate the other entries in the database. Unfortunately, doing a direct fetch with no flag does _not_ set the 'cursor,' so you can't do a direct fetch and then enumerate the table from there. The bug is that cached handles generated as the result of a YPPROC_MATCH were being treated as though they were the same as handles generated by a YPPROC_FIRST, which is not the case. The manifestation is that if you do a 'ypmatch first-key-in-map map' followed by a yp_first()/yp_next() pair, the yp_first() and yp_next() both return the first key in the table, which makes the entry appear to be duplicated. A couple smaller things since I'm here: - yp_main.c and yp_error.c both have a global 'int debug' in them. For some reason, our cc/ld doesn't flag this as a multiply defined symbol even though it should. Removed the declaration from yp_main.c; we want the one in yp_error.c. - The Makefile wasn't installing ypinit in the right place. |
| H A D | yp_main.c | diff 33250 Wed Feb 11 17:15:32 MST 1998 wpaul Fix a bug in the database handle caching. This has to do with the way the underlying database code works. When dealing with first/next queries, you have the notion of a database 'cursor,' which is essentially a file pointer for the database. To select the first entry, you do a fetch with the R_FIRST flag set, then you can use the R_NEXT flag to enumerate the other entries in the database. Unfortunately, doing a direct fetch with no flag does _not_ set the 'cursor,' so you can't do a direct fetch and then enumerate the table from there. The bug is that cached handles generated as the result of a YPPROC_MATCH were being treated as though they were the same as handles generated by a YPPROC_FIRST, which is not the case. The manifestation is that if you do a 'ypmatch first-key-in-map map' followed by a yp_first()/yp_next() pair, the yp_first() and yp_next() both return the first key in the table, which makes the entry appear to be duplicated. A couple smaller things since I'm here: - yp_main.c and yp_error.c both have a global 'int debug' in them. For some reason, our cc/ld doesn't flag this as a multiply defined symbol even though it should. Removed the declaration from yp_main.c; we want the one in yp_error.c. - The Makefile wasn't installing ypinit in the right place. |
| H A D | yp_server.c | diff 33250 Wed Feb 11 17:15:32 MST 1998 wpaul Fix a bug in the database handle caching. This has to do with the way the underlying database code works. When dealing with first/next queries, you have the notion of a database 'cursor,' which is essentially a file pointer for the database. To select the first entry, you do a fetch with the R_FIRST flag set, then you can use the R_NEXT flag to enumerate the other entries in the database. Unfortunately, doing a direct fetch with no flag does _not_ set the 'cursor,' so you can't do a direct fetch and then enumerate the table from there. The bug is that cached handles generated as the result of a YPPROC_MATCH were being treated as though they were the same as handles generated by a YPPROC_FIRST, which is not the case. The manifestation is that if you do a 'ypmatch first-key-in-map map' followed by a yp_first()/yp_next() pair, the yp_first() and yp_next() both return the first key in the table, which makes the entry appear to be duplicated. A couple smaller things since I'm here: - yp_main.c and yp_error.c both have a global 'int debug' in them. For some reason, our cc/ld doesn't flag this as a multiply defined symbol even though it should. Removed the declaration from yp_main.c; we want the one in yp_error.c. - The Makefile wasn't installing ypinit in the right place. |
Completed in 62 milliseconds