假设我们给出了一个字符串S,以及一些其他字符串L的列表.
我们怎么知道S是否是L的所有可能连接中的一个？
例如:
S ="abcdabce"
L = ["abcd","a","bc","e"]
S是"abcd"+"a"+"bc"+"e",则S是L的串联,而"ababcecd"则不是.
为了解决这个问题,我尝试使用DFS /回溯.伪代码如下:
boolean isConcatenation(S, L) {
if (L.length == 1 && S == L[0]) return true;
for (String s: L) {
if (S.startwith(s)) {
markAsVisited(s);
if (isConcatnation(S.exclude(s), L.exclude(s)))
return true;
markAsUnvisited(s);
}
}
return false;
}
但是,DFS /回溯不是一种有效的解决方案.我很好奇什么是解决这个问题的最快算法,或者是否有任何其他算法以更快的方式解决它.我希望有像KMP这样的算法可以在O(n)时间内解决它.
我知道在COM对象的AddRef和Release方法内部使用了互锁API来增加/减少引用计数线程的安全性.但我试图理解这里是使用Interlock API还是我们需要某种其他同步对象,例如Mutex.到目前为止,我见过的所有示例代码都只使用了Interlock API.
场景 - 假设我已经实现了消息对象的AddRef和Release方法,如下所示.假设线程A访问消息对象,因此m_lRef count为1.一旦完成消息对象使用线程A调用Release方法
内部释放方法 - 第9行 - m_lRef = 1第10行 - m_lRef = 0,lRef = 0
线程A在第10行暂停,另一个线程B访问相同的消息,因此它调用AddRef方法,该方法将第3行的m_lRef值设置为1.现在,线程B被挂起,线程A在第11行恢复 - m_lRef = 1,lRef = 0.线程A将删除该对象.现在,如果线程B试图访问同一个对象; 崩溃是不可避免的.
我的问题 - 我的情况有效吗？如果m_lRef = 1则理想情况下没有其他线程应该等待访问该对象.但是为了防止在这种意外情况下发生崩溃,我们不应该用互斥锁或CS保护整个释放方法吗？
1. STDMETHODIMP_(ULONG) CMapiMsg::AddRef()
2. {
3. LONG lRef = InterlockedIncrement(&m_lRef);
4. return lRef;
5. }
6.
7. STDMETHODIMP_(ULONG) CMapiMsg::Release()
8. {
9. LONG lRef = InterlockedDecrement(&m_lRef);
10. if(0 == lRef)
11. {
12. delete this;
13. }
14. return lRef;
15. }
我使用_stat64(const char *path, struct __stat64 *buffer);API 来获取文件/目录统计信息，但如果输入路径包含符号链接，则此 API 会失败。
GetFileAttributes()GetFileAttributesEx()如果文件路径包含符号链接，API 也会失败。但正如MSDN 所述，如果路径指向符号链接，则这两个函数返回符号链接的属性。即使_stat64()路径指向符号链接也有效。
如果路径包含[不指向]符号链接，有没有办法获取文件/目录的状态/属性？
例如 -如果输入路径是“D:\temp\ symbolic_link \test”，如何获取“ test ”目录的属性
[Edit1] 由于 eryksun 的评论是有道理的。我再次尝试了 GetFileAttributesEx() 和 _stat64()。它起作用了，但这次我授予了目标目录和符号链接的完全权限。这似乎是权限问题。如果我通过“D:\temp\ symbolic_link ”然后我得到符号链接的属性/统计，如果我通过“D:\temp\ symbolic_link \test”然后我得到预期的测试目录的属性/统计。
Fortify在下面的代码中报告了一个缓冲区溢出漏洞,理由如下:
在这种情况下,我们主要关注案例"取决于在代码的直接范围之外强制执行的数据的属性".,因为我们无法验证abc.cpp中memcpy()执行的操作的安全性
void create_dir(const char *sys_tmp_dir, const char *base_name,
size_t base_name_len)
{
char *tmp_dir;
size_t sys_tmp_dir_len;
sys_tmp_dir_len = strlen(sys_tmp_dir);
tmp_dir = (char*) malloc(sys_tmp_dir_len + 1 + base_name_len + 1);
if(NULL == tmp_dir)
return;
memcpy(tmp_dir, sys_tmp_dir, sys_tmp_dir_len);
tmp_dir[sys_tmp_dir_len] = FN_LIBCHAR;
memcpy(tmp_dir + sys_tmp_dir_len + 1, base_name, base_name_len);
tmp_dir[sys_tmp_dir_len + base_name_len + 1] = '\0';
..........
..........
}
在我看来这是一个误报,因为我们首先得到数据的大小,分配大量的空间,然后调用memcpy大小来复制.但我正在寻找有充分理由说服其他开发人员摆脱当前的实现,而不是使用c ++字符串.这个问题已经分配给他了.他只是认为这是一个误报,所以不想改变任何东西.
编辑我看到对当前代码的快速,有效的批评.希望我现在能够说服他.否则,我会拿着接力棒.:)
我正面临这个奇怪的问题.要删除文件,请在我的代码中调用unlink() API.此调用将删除该文件并在非Windows平台上成功.在Windows上它成功(返回0)但不删除该文件.
为了实验我添加了一个循环来重复调用相同的API.在第二次迭代中,我得到了一个Permission denied错误,错误代码= 13.虽然在文件中设置了读/写属性,但程序具有访问该文件的完全权限.
然后我调用DeleteFile()而不是unlink()API.令我惊讶的是,我看到相同的结果,调用成功,即返回1但文件未被物理删除.
我通过unlocker实用程序检查,除了试图删除此文件的程序之外,没有其他程序正在访问该文件.
有谁知道还有什么可能是错的？
Edit1: 只是为了确保在删除文件时没有打开文件.我在创建文件时保存了句柄,并在删除文件之前尝试关闭但是我收到错误"'UNOPENED'(错误代码:9 - 错误的文件描述符)".因此,我得出结论,该文件在删除时未打开.
Edit2 根据要求,这是用于创建和删除文件的代码的简化版本.
// Code to create the file
int create_file(const char* path)
{
HANDLE osfh; /* OS handle of opened file */
DWORD fileaccess; /* OS file access (requested) */
DWORD fileshare; /* OS file sharing mode */
DWORD filecreate; /* OS method of opening/creating */
DWORD fileattrib; /* OS file attribute flags */
SECURITY_ATTRIBUTES SecurityAttributes;
SecurityAttributes.nLength= sizeof(SecurityAttributes);
SecurityAttributes.lpSecurityDescriptor= NULL;
SecurityAttributes.bInheritHandle= !(oflag & _O_NOINHERIT);
fileaccess= …这是一个现有代码,它找到与父路径相对应的相对路径.它已经在平台上正常工作,除了SUSE 12和GCC 4.7. 我已经提到了一个错误的输出,并在评论中预期. 我想知道为什么会这样？ 这段代码有什么问题？ 子字符串和父字符串都以NUL字符结尾.我看到的唯一另一件事是源和目标从同一个内存位置传递,换句话说我们正在尝试更新相同内存位置的值.这是真正的问题吗？
//child = /dev/shm/4/tmp/backup/datadir/performance_schema/events_stages_summary_by_account_by_event_name.frm
//parent = /dev/shm/4/tmp/backup
char* get_relative_path(char *child, const char *parent)
{
char* start= child;
static char dot[] = "." ;
....
....
/* Check if child = parent + "/" + .... */
if (strstr(child, parent) == child)
{
int parent_len= strlen(parent);
/* parent path may or may not have the "/" suffix. check for both. */
if (parent[parent_len-1] == FN_LIBCHAR ||
child[parent_len] == FN_LIBCHAR)
{
child+= parent_len;
while (*child && …我知道这是未定义的行为。因此存在数据竞争或崩溃的可能性。可以使用atomicbool来避免这种可能性。我有兴趣了解有关碰撞安全的信息。
AFAIU，当一个线程读取另一个线程部分写入或撕裂的值时，可能会发生崩溃。另一方面， bool 的大小是由实现定义的，但让它大于数据模型中指针的大小几乎没有意义。
假设 bool 的内存块将被更新或不更新是否安全？因此，其他线程无法读取撕裂值，因此从不同线程读取/写入全局布尔值是安全的吗？